AI Agents

171 posts

dropbox3 min readCurated summary

Beyond code generation: rethinking engineering productivity in the age of AI agents

AI coding agents have increased Dropbox’s code production, but they have also exposed bottlenecks in review, testing, release coordination, and operations. The central argument is that engineering productivity must be measured by end-to-end product velocity and customer impact—not code or pull-request volume alone. Dropbox is responding with agent platforms, stronger workflow infrastructure, broader quality metrics, and training that helps engineers adapt to new responsibilities. ## From Copilots to Agents - Copilots assist with explanations, snippets, and questions within existing workflows. - Agents can take scoped tasks, inspect repositories, edit files, run tests, fix failures, and return changes for human review. - Engineers remain responsible for intent, architecture, quality, and release decisions. - Increased parallel work and code output create new pressure on: - Code review systems - CI and testing infrastructure - Validation workflows - Release processes - Production operations - More code and pull requests do not necessarily create more customer value. ## Nova as Dropbox’s Agent Platform - Nova runs AI coding agents in controlled environments with relevant codebase context and internal engineering practices. - Its value comes from the surrounding platform—safe execution, workflow integration, guardrails, and human review—not only from the underlying model. - Nova generates approximately one in twelve Dropbox pull requests. - It supports both feature work and maintenance tasks, including: - Migrations - Flaky-test remediation - Bug investigation - Dependency updates - Other high-effort engineering work - The intended workflow is structured: define the task, let the agent work within constraints, validate the result, and require human approval before production. ## Measuring Product Velocity and Impact - Pull-request throughput was useful when implementation speed was the main constraint, but it is insufficient as AI increases output. - Dropbox evaluates whether the broader engineering system can absorb additional work efficiently. - Its four-stage measurement model tracks: - **Fuel:** Whether engineers use AI tools - **Adoption:** How teams change their workflows - **Output:** Whether AI contributes to production work - **Impact:** Whether products reach customers faster and create greater value - Quality and trust metrics include review turnaround time, first-run test pass rate, defect ratio, and rework rate. - Productivity improvements must not come at the expense of reliability or customer trust. ## Evolving Engineering Workflows - Engineers increasingly focus on defining intent, framing problems, reviewing changes, and making architectural and quality decisions. - Adoption requires more than tools; Dropbox uses hands-on learning, hackathons, bootcamps, workflow examples, and peer-led training. - Teams should adopt agents at different speeds based on risk, context, and readiness. - The goal is not to automate every workflow, but to make agentic development safe, useful, measurable, and repeatable. ## Broader Lessons - AI does not remove bottlenecks; it shifts them downstream. - Organizations must invest in validation, orchestration, governance, workflow integration, and measurement alongside code generation. - Competitive advantage will come less from access to common foundation models and more from the systems built around them: internal context, safeguards, quality controls, and integrated engineering workflows. Dropbox’s experience suggests that companies should treat AI agents as a change to the entire software delivery system, not merely as faster coding tools. The strongest results will come from improving the full path from idea to validated production impact.

Read original(opens in new tab)
cloudflare3 min readCurated summary

How we built Cloudflare's data platform and an AI agent on top of it

Cloudflare built Town Lake to unify data scattered across production databases, analytics systems, streams, and object storage behind one governed SQL interface. The platform combines Trino, Iceberg on R2, DataHub, and custom access-control and PII-detection services to make data fresher, more discoverable, and safer to use. Skipper extends Town Lake with a natural-language AI interface intended to provide fast, accurate, and auditable answers without requiring users to write SQL. ## The Data Sprawl Problem - Cloudflare processes over a billion events per second across a network spanning more than 330 cities and 120 countries. - Relevant data was distributed across: - Postgres - ClickHouse - BigQuery - Kafka - Google Cloud Storage and R2 - Numerous pipelines and production databases - Users needed separate credentials, query languages, retention expectations, and system knowledge for each source. - Sampled analytics data worked for dashboards but was unsuitable for billing, usage calculations, and security investigations. - External vendors created cost and dependency concerns. - Important data was difficult to discover because table locations, schemas, joins, and customer-ID mappings depended on tribal knowledge. - Data infrastructure had historically been treated as a back-office service rather than core company infrastructure. ## Goals for the New Platform Cloudflare wanted a single place where authorized employees could answer questions about customers, traffic, billing, security events, and support activity. - Support both: - Fresh, accurate, unsampled data for billing and investigations - Fast, downsampled data for dashboards and exploration - Provide built-in governance: - Automatic PII detection - Sensitive tables locked down by default - Auditable access - Time-limited permission grants - Build the system using Cloudflare’s own products, including R2, Workers, Access, and Workflows. - Eventually let employees ask questions in plain English rather than requiring SQL knowledge. - That natural-language interface became Skipper. ## Town Lake’s Lakehouse Architecture Town Lake is a lakehouse: a query engine combines data from object storage and operational systems while a metadata layer makes the data behave like a unified database. - **Trino** serves as the query engine. - A single query can join Postgres, ClickHouse, and Iceberg tables stored on R2. - Trino pushes filters into source systems and combines results without requiring intermediate materialization. - **R2 Data Catalog and Apache Iceberg** store warm and cold data. - Iceberg provides schema evolution, time travel, partition evolution, and compaction. - Data can be rolled from per-minute to hourly and eventually daily granularity as it ages. - Older data becomes cheaper to store while remaining queryable. - Parquet files on R2 cost less than retaining equivalent data in an OLAP database. - **DataHub** provides the metadata catalog. - It stores table and column descriptions, owners, lineage, and glossary terms. - Users can discover what a table contains, which teams maintain it, and how it relates to upstream and downstream data. ## Access Control and Privacy - **Lifeguard** manages access policies. - Rules are stored in D1. - User and group memberships are retrieved dynamically from Cloudflare’s internal access-management system. - Lifeguard produces JSON policies that Trino reads over HTTP. - It also supplies access information to Skipper and the Gateway, allowing users to be blocked before queries execute. - **Skimmer** continuously scans tables for PII. - It samples rows from columns across the data platform. - Workers AI classifies whether columns contain personally identifiable information. Cloudflare’s overall approach is to combine unified querying, durable low-cost storage, rich metadata, and policy enforcement so data can be broadly useful without sacrificing accuracy or governance.

Read original(opens in new tab)
gitlab2 min readCurated summary

Claude Opus 4.8 on GitLab: Complex agentic work, less disruption

Claude Opus 4.8 is now available in GitLab Duo Agent Platform for complex, multi-step coding and agentic workflows. The model is designed to follow instructions more precisely over extended autonomous runs, reducing the need for human correction and intervention. It also supports mid-conversation system-prompt updates without invalidating the prompt cache, making it better suited to changing contexts. ## Improved Long-Horizon Agentic Execution - Handles complex workflows involving multiple tools and extended sequences. - Provides more comprehensive planning and reasoning. - Produces more accurate end states with fewer interruptions or redirects. - Interprets instructions more precisely than previous models. - Supports professional tasks beyond coding, including: - Document drafting - Data analysis - Structured knowledge work ## Mid-Conversation System Prompts - System instructions can change during an active session. - Prompt-cache validity is preserved when context changes. - This is useful when: - Files change on disk - Token budgets shift - User context is updated - Asynchronous information arrives ## Availability and Pricing - Available through model selection in Agentic Chat and across GitLab Duo agent workflows. - Runs on GitLab Credits. - GitLab Premium and Ultimate subscribers can use included credits. - New users can access it through a GitLab Duo Agent Platform trial or the GitLab Free tier. Teams seeking more reliable autonomous coding and documentation workflows can use Opus 4.8 in GitLab Duo to reduce manual oversight while agents complete longer, more complex tasks.

Read original(opens in new tab)
figma2 min readCurated summary

Figma Make, Now on Your Local Code | Figma Blog

Figma is bringing Make beyond prototyping by connecting it directly to local production codebases. Designers can visually edit interfaces, use annotations and prompts for more complex behavior, and manage changes through Git workflows without leaving Figma. The broader goal is to make design and code a continuous, collaborative workflow rather than separate tools. ## Visual Editing in Production Code - Make connects to a local codebase and translates visual changes into code. - Users can select interface elements and modify: - Layouts - Colors - Fonts - Sizing - Other visual properties - Annotations let users describe interactions, animations, and other changes that go beyond simple property edits. - The feature is currently best suited to designers who already have access to their organization’s codebase. ## Git-Based Branching and Shipping - Make supports standard development workflows, including: - Creating branches - Reverting commits - Reviewing commit history - Creating pull requests - Changes remain in local commits until the team intentionally opens a pull request. - Engineering teams can review Make-generated changes like any other production contribution. ## Collaboration Between Design and Code - Local code changes can be shared as files and links with teammates who have access to the relevant branch. - Teammates can inspect changes, build on them, and compare versions through commit history. - Screens, pages, and components can be copied from Make into Figma Design as editable layers. - Changes made in Figma can be detected and brought back into Make, creating a round-trip workflow between the design canvas and codebase. ## Beta Availability - Direct editing, annotations, chat, and pull-request creation enter limited beta on May 28, 2026. - Beta access is limited to Figma’s Mac desktop beta app and requires joining a waitlist. - The features will not consume credits during beta; pricing for AI credits will be announced later. - Figma plans to expand availability to other platforms. Figma’s recommendation is effectively to use whichever environment best fits the current task—design canvas, code-based prototyping, or production code—while maintaining a shared workflow between them.

Read original(opens in new tab)
line4 min readCurated summary

ODW #7: Reduce Token Consumption by 40% in Three Ways! Context Engineering with ADK

The post explains how LY Corporation’s Orchestration Development Workshop uses context engineering to reduce AI-agent costs and improve accuracy. As internal adoption of tools such as Claude Code, Cline, and ADK grows, excessive token usage, missed instructions, and declining performance in long conversations have become common. The recommended solution is to deliberately select and manage the context sent to an LLM, demonstrated through an ADK-based Jira weekly-report agent. ## Problems Caused by Expanding AI Use - Increased AI adoption has led to unexpectedly high token consumption. - Users often receive incomplete or incorrect results despite providing detailed prompts. - Long-running conversations can cause the model to produce irrelevant answers. - Major causes include: - Trial-and-error prompting - More complex and long-running agents - Expansion from single-agent to multi-agent systems - Tool integrations such as MCP, whose definitions also consume context - Limited awareness of context optimization techniques ## Context Rot and Context Engineering - **Context rot** occurs when long-running agents accumulate conversation history, intermediate results, and irrelevant information. - As the context grows: - The context window becomes pressured. - Relevant information becomes harder to identify. - Noise overwhelms important signals, reducing accuracy. - Context engineering is the deliberate design and management of all information provided during inference, including: - **Static context:** System prompts and tool definitions - **Dynamic context:** User messages, conversation history, and retrieved external data - **Long-term context:** Persistent session state and accumulated information - The core principles are: - Treat tokens as a limited resource and retain the smallest set of high-signal information. - Provide neither too little information, which forces guesswork, nor too much, which wastes tokens and reduces clarity. ## Why Use ADK Google’s open-source Agent Development Kit (ADK) is presented as a practical platform for applying context engineering. - Agents can be designed and shared using team knowledge rather than relying on individual CLI expertise. - ADK includes UI, API-server, evaluation, and multi-agent capabilities. - Its multi-agent architecture naturally supports separating and controlling context. ## ADK Context-Engineering Components The workshop introduces nine key components, including: - **Structured input and output:** JSON or schema-based formats reduce unnecessary text and make agent processing more reliable. - **AgentTool:** Embeds one agent inside another as a tool. The calling agent receives only the final result, preventing internal tools and intermediate context from accumulating. - **MCP Toolset filtering:** The `tool_filter` parameter exposes only required MCP tools, reducing tool-definition tokens and improving model decisions. - The remaining components can be combined with these techniques to control context throughout an agent workflow. ## Jira Weekly Report Example The workshop builds `jira_weekly_report`, an agent that analyzes team Jira tickets and generates a weekly Markdown report. ### Version 1: Single Agent Without Context Engineering - A single agent retrieves the ticket list, fetches each ticket, analyzes it, and builds the report. - All Jira tools are exposed through one MCP toolset. - As the number of tickets increases, detailed ticket contents accumulate in the agent’s context. - This leads to context rot, higher token usage, and declining reliability. ### Version 2: Context-Aware Multi-Agent Design - The workflow is split into: - A root agent that searches Jira tickets and aggregates the final report. - A sub-agent dedicated to analyzing one ticket at a time. - `input_schema` requires a structured `issue_key`. - `output_schema` requires a structured report containing ticket content and progress, including comments. - The sub-agent receives only the `jira_get_issue` MCP tool. - The root agent receives only the `jira_search` tool. - `AgentTool` hides the sub-agent’s internal context and returns only its final report. - The sub-agent is instructed to include facts only and avoid speculation. This design limits each agent’s responsibilities, removes unnecessary tool definitions, and prevents individual ticket details from polluting the root agent’s context. ## Practical Recommendation For production AI agents, treat context as a constrained resource. Use structured schemas, narrowly filtered tools, and specialized sub-agents to pass only the information needed for each step.

Read original(opens in new tab)
gitlab2 min readCurated summary

Transform MRs from manual tasks to an automated workflow

GitLab 19.0 expands Developer Flow from generating merge requests to managing much of their entire lifecycle. Its AI agent can respond to reviews, investigate codebases, resolve conflicts, and split oversized MRs, while automation handles rebasing and merging. The result is less manual effort between opening and merging an MR, with developers supervising rather than executing every step. ## Developer Flow Across the MR Lifecycle - Can be triggered from: - An issue via **Generate MR** - An issue or MR assigned to the **Duo Developer** service account - Any issue or MR discussion using the new **@mention** trigger - Continues working on the same MR instead of creating separate changes to reconcile. - Handles: - Multiple rounds of reviewer feedback - Merge conflicts on long-running branches - Codebase research and technical evaluations - Oversized MR splitting - New feature implementation - Uses a single agentic loop with tools such as `read`, `grep`, file editing, and command execution. - Reads `AGENTS.md` for project conventions and operational guidance. - Uses `agent-config.yml` to configure dependencies, tooling, tests, and pre-commit hooks. These capabilities are available through GitLab Duo Agent Platform on Premium and Ultimate plans. ## Autonomous Merge Conflict Resolution - The beta **Resolve with Duo** button is available on the MR conflict page and merge checks widget. - The agent: - Reviews the MR’s intent and both branches - Selects a resolution strategy - Edits conflicting files - Commits and pushes the resolution - It leaves a summary comment explaining the conflict and resolution path. - If it cannot resolve the conflict safely, it reports that rather than guessing. ## One-Click Rebase and Merge - The beta feature combines rebasing and merging into one action. - It is designed for teams using semi-linear or fast-forward merge methods. - It is available on Free, Premium, and Ultimate tiers. ## Reducing Manual MR Work GitLab distinguishes between AI-driven judgment and mechanical automation: - AI handles code changes, reviewer feedback, and conflict resolution. - Automation handles tasks such as rebasing before merge. - Together, these features reduce the time developers spend on repetitive MR maintenance while preserving human oversight for steering, reviewing, and final decisions. Developers can try Developer Flow through a GitLab Duo Agent Platform trial. Existing Premium and Ultimate users with the platform can use it on merge requests, while older GitLab versions may require manually configuring the mention trigger.

Read original(opens in new tab)
gitlab2 min readCurated summary

Beyond BYOK: Why governance matters for AI agents

BYOK and local models give developers more control over which AI systems they use, but they do not provide enterprise governance by themselves. The post argues that AI agents operating in CI/CD need platform-level controls for authorization, security, and auditing, especially when no human is present. It presents GitLab Duo CLI and its Agent Platform as a governance-oriented alternative for controlled, auditable automation. ## Terminal AI: Individual Tool vs. Platform - Copilot’s BYOK and local-model support primarily extend AI capabilities at an individual developer’s workstation. - The post argues these features do not enforce organization-wide model policies or provide a complete audit trail of agent actions. - GitLab Duo CLI is positioned for both interactive development and automated workflows across multiple projects and release cycles. - Its headless mode allows it to run non-interactively and scriptably inside CI/CD pipelines. ## Why Model Choice Is Not Governance - Interactive coding tools generally assume a human reviews every action. - Automated agents can run tests, modify configuration, and perform multi-step delivery tasks without continuous oversight. - Enterprise governance therefore requires answers to questions such as: - What resources can the agent access? - Which actions is it authorized to perform? - Can the organization prove what the agent did? - GitLab’s platform-level controls include: - Human approval for actions in interactive mode. - Prompt-injection detection. - Composite identity scopes limiting agent access. - `AGENTS.md` and `SKILL.md` files for defining permitted tasks and actions. ## CI/CD Automation Requires Consistent Controls - Potential use cases include debugging failed pipelines and completing multi-step development work. - Pipeline-based agents cannot rely on a developer to detect prompt injection or unexpected behavior. - Security controls must therefore be built into the platform and applied consistently across workflows and environments. ## Model Flexibility and Data Sovereignty - The post recommends evaluating whether AI tooling maintains its security model when no human is watching. - GitLab Duo CLI supports both self-hosted and GitLab-hosted models. - Organizations can keep sensitive workloads on infrastructure they control while using hosted models for other tasks. ## Practical Recommendation Model flexibility is useful, but production adoption depends on governance. Teams considering AI agents for CI/CD should prioritize authorization, auditing, prompt-injection protection, and consistent platform controls—not just BYOK or offline execution.

Read original(opens in new tab)
spotify3 min readCurated summary

Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify | Spotify Engineering

Spotify argues that AI has shifted software development’s main constraint from writing code to coordinating people, systems, and decisions. Years of investment in standardized platforms, automation, and developer experience enabled Spotify to adopt AI coding tools at extraordinary scale. The company’s experience suggests that consistent infrastructure and strong feedback loops are essential for making both human developers and coding agents effective. ## Rapid AI Adoption - More than 99% of Spotify engineers use AI coding tools weekly. - 94% report improved productivity. - Pull request frequency has increased by 76%, with most PRs created by developers working alongside AI agents. - Adoption accelerated sharply after the release of Claude Opus 4.5. ## Fleet Management Before AI Agents - Spotify’s codebase was growing seven times faster than its engineering workforce. - Developers increasingly spent time on dependency upgrades, API migrations, and vulnerability fixes. - Fleet Management automated changes across hundreds or thousands of components. - Its orchestration system, Fleetshift, has merged more than 2.5 million maintenance PRs, most without human intervention. - This approach reduced migrations from work taking weeks or months across many teams to centrally managed operations. ## Honk: A Background Coding Agent - Deterministic scripts struggled with complex refactoring and the edge cases found across large codebases. - Spotify created Honk, a background coding agent powered by Claude through the Agent SDK. - Honk runs in Kubernetes pods, allowing many coding sessions to execute concurrently. - It can use trusted tools and run builds in CI across multiple operating systems. - Fleetshift identifies targets, schedules work, and tracks PRs, while Honk performs the code changes. - A recent Java migration across Spotify’s backend services took three days. - Engineers can invoke Honk through Slack, where it uses conversation context to create and return PRs. - Honk v2 adds shared sessions, team projects, and agent orchestration through Chirp. ## Standardization Improves Agent Performance - Spotify’s principle of limiting the number of technologies it supports reduces decisions and improves collaboration. - Consistent service architectures and design patterns also give AI agents better reference material. - Agents perform worse in fragmented codebases with inconsistent conventions. - Backstage provides a unified internal developer portal and catalog for software components. - Spotify exposes Backstage capabilities to agents through MCP integrations and command-line tools. - Agents can discover component ownership, read documentation, and contact responsible teams. ## Guardrails Through Backstage - Backstage’s Soundcheck and “golden state” define recommended technologies and practices. - Teams can assess their components against these standards. - Static analysis and linting provide immediate feedback when developers or agents use unsuitable patterns. - This creates a feedback loop that helps agents correct their work and drives consistency across the organization. Spotify’s experience indicates that scaling AI development requires more than giving engineers access to models. Organizations should invest in standardized platforms, searchable component metadata, automated fleet-wide workflows, and strong validation systems so agents can operate reliably at team scale.

Read original(opens in new tab)
gitlab3 min readCurated summary

Fix bugs with Codex and GitLab

Codex accelerates coding in the terminal, but producing a fix is only one part of shipping software. GitLab supplies the surrounding lifecycle: issues, merge requests, CI/CD, security scanning, code review, and human approval. The tutorial demonstrates this progression through a Rust WebSocket bug, first with local Codex, then with GitLab MCP for issue context, and finally with Codex as an external agent in GitLab Duo Agent Platform. ## Prerequisites and Project Setup - Configure Codex in the terminal, Rust/Cargo, and access to a GitLab project. - Import and clone the Tanuki IoT Platform project, then launch Codex from its repository root. - The tutorial focuses on `backend/`, where: - Sensors submit readings through a REST API. - Dashboards receive live readings through WebSocket streams. - `AGENTS.md` provides Codex with repository structure, toolchain instructions, build commands, and quality expectations. ## Reproducing the WebSocket Filtering Bug - Start the Rust metrics backend on port `9090`: ```bash PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml ``` - Connect to a filtered WebSocket stream: ```bash websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius' ``` - Submit both temperature and humidity readings for the same sensor through the REST API. - The stream incorrectly returns both metrics instead of only `temperature_celsius`, proving that the WebSocket handler does not apply the metric filter. ## Fixing the Bug with Codex - Give Codex a focused request to add metric filtering to `/ws`. - Codex examines the Rust source and identifies that the endpoint already supports `sensor` filtering but lacks an optional `metric` condition. - It updates the handler, adds tests, and keeps documentation aligned with the implementation. - Codex runs formatting, tests, and builds before creating a branch, committing, and pushing the change. - Once the merge request is created, GitLab handles: - CI/CD pipelines - Security scanning - GitLab Duo Code Review - A follow-up WebSocket test confirms that supplying both sensor and metric now returns only the requested metric. ## Adding GitLab Context with MCP - Local Codex can inspect repository files, but it cannot automatically see GitLab issues, requirements, implementation notes, merge-request discussions, or pipeline status. - The GitLab MCP server connects Codex to that development lifecycle context. - Codex can retrieve the existing issue directly instead of requiring the developer to copy its contents into the prompt. - The issue acts as the shared source of truth and includes: - The bug description - Functional behavior requirements - Non-functional requirements - Required tests - Updates to `README.md` and `AGENTS.md` - Implementation notes - This helps Codex produce a fix that satisfies the agreed requirements rather than merely addressing the symptom visible in the local code. ## Using Codex as an External GitLab Agent - The tutorial’s third workflow uses Codex inside GitLab Duo Agent Platform as an external agent. - This allows the agent to participate after the merge request is open, particularly when addressing review feedback. - GitLab remains the system coordinating issues, merge requests, pipelines, reviews, and deployment, while Codex contributes its terminal-oriented coding capabilities. - The overall workflow moves from bug report to implementation, automated validation, review feedback, revisions, and an informed human decision to ship. ## Practical Conclusion Use Codex for fast, repository-local implementation, but connect it to GitLab through MCP or Duo Agent Platform when requirements and review context matter. The strongest workflow combines Codex’s coding speed with GitLab’s issue-aware, automated, and human-governed delivery lifecycle.

Read original(opens in new tab)
aws2 min readCurated summary

Amazon Redshift introduces AWS Graviton-based RG instances with an integrated data lake query engine | Amazon Web Services

Amazon Redshift introduces RG instances powered by AWS Graviton, targeting lower-cost, higher-volume analytics for both human users and AI agents. RG instances can run warehouse workloads up to 2.2× faster than RA3 at 30% lower price per vCPU, while an integrated data lake engine enables faster SQL queries across warehouse tables and S3 data. The architecture also removes the need for Redshift Spectrum and its per-terabyte scanning fees. ## Performance and Cost Improvements - RG instances deliver: - Up to 2.2× faster data warehouse workloads than RA3. - 30% lower pricing per vCPU. - Up to 2.4× faster queries on Apache Iceberg data. - Up to 1.5× faster queries on Apache Parquet data. - The improvements are designed for: - Low-latency BI dashboards. - ETL pipelines and near-real-time analytics. - High-volume queries generated by autonomous AI agents. - AWS recommends using the AWS Pricing Calculator to estimate savings for specific workloads. ## Integrated Data Lake Query Engine - RG instances query warehouse tables and S3 data lakes through one engine. - Data lake queries run directly on Redshift cluster nodes rather than through Redshift Spectrum. - Existing external tables, schemas, Spectrum queries, and SQL syntax remain unchanged. - Customers do not need to recreate external tables or modify application code. - Queries remain inside the customer’s VPC, use existing IAM roles, and avoid Spectrum’s former $5-per-terabyte scanning charge. ## Migration and Setup - RG clusters can be created or migrated through: - The AWS Management Console. - AWS CLI. - AWS API. - The integrated data lake engine is enabled by default. - Migration options include: - **Elastic Resize:** In-place migration with approximately 10–15 minutes of downtime for compatible configurations. - **Snapshot and Restore:** Creates an RG cluster from an RA3 snapshot and is useful when configuration changes are needed. ## Availability and Pricing Options - RG instances are available across numerous AWS Regions in North America, Europe, Asia-Pacific, Canada, and South America. - Redshift Provisioned customers can choose: - On-Demand Instances with hourly billing and no commitment. - Reserved Instances for additional savings. RG instances are intended for organizations combining data warehouse and data lake workloads, especially those needing lower costs and fast response times at high query volumes. Customers should test compatibility and use workload-specific pricing estimates before migrating.

Read original(opens in new tab)
aws3 min readCurated summary

AWS Weekly Roundup: Amazon Bedrock AgentCore payments, Agent Toolkit for AWS, and more (May 11, 2026) | Amazon Web Services

The May 11, 2026 AWS roundup highlights growing support for autonomous AI agents, especially through Amazon Bedrock AgentCore’s managed payment capabilities. It also covers new tools for building secure agents on AWS, enhanced WorkSpaces automation, faster EC2 instances, and updates across Valkey, vector search, and agentic SRE operations. ## AgentCore Payments for Autonomous Agents - Amazon Bedrock AgentCore previewed managed payments for AI agents. - Agents can autonomously pay for: - APIs - MCP servers - Web content - Other agents - The service was developed with Coinbase and Stripe to handle billing, credentials, and compliance. - Developers can connect: - Coinbase CDP wallets - Stripe Privy wallets - Session-level spending limits help control agent transactions. - Potential applications include research agents purchasing live market data and coding agents calling paid APIs during execution. ## New Tools for Building AI Agents on AWS - **Agent Toolkit for AWS** provides production-ready tools and guidance at no additional charge. - It aims to reduce coding errors and token usage while adding enterprise security controls. - The toolkit replaces AWS Labs’ earlier MCP servers, plugins, and skills. - **AWS MCP Server** is now generally available as a managed, remote MCP server. - It provides secure, authenticated access to AWS services. - Agents interact through a small, standardized set of tools. - It is included in the Agent Toolkit for AWS. ## AI-Controlled Workspaces and New EC2 Instances - **Amazon WorkSpaces for AI agents** entered preview. - Agents can securely access and operate desktop applications. - Managed WorkSpaces environments provide governance and compliance controls. - The capability targets large-scale automation of everyday workflows. - New **EC2 M8idn/M8idb and R8idn/R8idb instances** use sixth-generation Intel Xeon processors and AWS Nitro cards. - They provide up to 43% better compute performance per vCPU than prior generations. - M8idn and R8idn offer up to 600 Gbps of network bandwidth. - M8idb and R8idb offer up to 300 Gbps of EBS bandwidth. ## Valkey and Vector Search Updates - Valkey, the community-driven Redis alternative, marked its second anniversary. - It has surpassed: - 100 million Docker pulls - 225 contributors - 1,500 pull requests - Valkey’s development pace is described as roughly twice that of Redis over the same period. - Valkey 9.0 is available through Amazon ElastiCache. - Amazon Aurora PostgreSQL-Compatible Edition can query billion-scale Amazon S3 Vectors using standard SQL. - Vector similarity searches can be combined with relational filters, such as price, inventory, or tenant, in a single query. ## Agentic Site Reliability Engineering - AWS DevOps Agent can be configured with “Spaces” that define investigation scopes. - It integrates with Amazon CloudWatch, Splunk, GitHub, and Slack. - Webhooks can trigger automated investigations. - The system can create mitigation plans and produce agent-ready specifications for coding tools such as Kiro. AWS’s latest updates emphasize autonomous agents that can transact, operate software, investigate incidents, and interact with cloud services while remaining governed by enterprise security and spending controls. Teams interested in these capabilities should start with the Agent Toolkit for AWS and explore the related previews and documentation.

Read original(opens in new tab)
gitlab4 min readCurated summary

GitLab Act 2

GitLab is restructuring its organization and strategy to prepare for an agent-driven software industry. It expects AI agents to dramatically increase software production, making scalable infrastructure, orchestration, context, and governance more important than traditional developer tooling. The company is reducing geographic footprint and management layers while reorganizing R&D around smaller, autonomous teams, reaffirming its FY27 guidance pending final restructuring costs. ## Organizational Restructuring - GitLab is conducting the process openly, including a voluntary separation window. - The new organizational shape is expected to be finalized by June 1 where possible; local legal processes may extend timelines. - Planned operational changes include: - Reducing the number of countries with small GitLab teams by up to 30%, while relying on partners in affected markets. - Removing up to three management layers in some functions. - Reorganizing R&D into approximately 60 smaller teams with end-to-end ownership. - Automating internal reviews, approvals, and handoffs with AI agents, then adjusting roles accordingly. - The restructuring and strategic shift are related but independently justified. - GitLab will disclose the restructuring’s final scope and financial impact during its June 2 earnings call. ## Software Development in the Agentic Era - Software will increasingly be produced by machines under human direction. - Agents will plan, code, review, deploy, and repair software. - Engineers will remain responsible for architecture, customer understanding, judgment, and difficult tradeoffs. - Lower software-production costs are expected to expand demand for software and increase the value of developer platforms. - Deep engineering skills—such as system design, distributed systems, failure analysis, and integrating new capabilities safely—will become more important and scarce. - GitLab points to its Duo Agent Platform, released in January, as an initial investment in this future. ## Infrastructure for Machine-Scale Development - Agents can create merge requests, trigger pipelines, and push commits at volumes far beyond human teams. - Git and existing development platforms were not designed for this level of activity. - GitLab plans to: - Reengineer Git for machine-scale workloads. - Replace parts of its monolithic architecture with API-first, composable services. - Provide agent-specific APIs so agents can interact as first-class platform users. - The company argues that reliability, performance, and scalability at this level will become a major source of platform value. ## Orchestration Across the Software Lifecycle - Enterprises need more than individual agents that generate code or open merge requests; they need software that reaches production and delivers business value. - GitLab’s orchestration layer is intended to coordinate agents across the lifecycle by: - Assigning work and managing state. - Passing context between tasks. - Resolving conflicts. - Enforcing policies and guardrails. - Keeping humans involved where judgment is required. - CI/CD is being reconsidered as part of this shift, with orchestration serving as the runtime for validating and safely deploying machine-rate changes. ## Context as a Competitive Advantage - Code generation capabilities are increasingly similar across developer-tool vendors. - GitLab believes its advantage lies in the connected context accumulated across planning, code, review, security, deployment, and operations. - It plans to make this data model a first-class, API-accessible service. - More contextual information should allow agents to use fewer tokens and produce better results. ## Governance Built Into the Platform - As agents perform more work, enterprises need strong control over identity, permissions, policies, auditing, and data location. - GitLab intends to make governance core infrastructure rather than an add-on product. - Every agent, pipeline, and merge request should operate through platform services that can: - Control who or what may perform an action. - Record what happened and why. - Protect sensitive code and data. - Support flexible deployment models. ## One Platform, Three Modes - GitLab notes that most business software cannot realistically be rewritten for the agentic era. - Its platform strategy is therefore intended to support existing codebases alongside newer development models. - The provided text ends before explaining the three modes in detail. GitLab’s overall recommendation to itself is to reshape both its organization and platform around machine-scale software development, while preserving human control over architecture, judgment, and governance.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Building For The Future

Cloudflare announced plans to eliminate more than 1,100 jobs as it restructures for an “agentic AI era.” The company says the decision reflects a fundamental redesign of internal processes, teams, and roles—not individual performance or a conventional cost-cutting exercise. Leaders argue that acting decisively now will reduce prolonged uncertainty and create a faster, more innovative organization. ## Restructuring Around Agentic AI - Cloudflare’s internal AI usage has increased by more than 600% in three months. - Employees across engineering, HR, finance, marketing, and other departments run thousands of AI-agent sessions daily. - Because Cloudflare uses AI extensively itself, leadership says the company must redesign how work is organized to capture its benefits. - The restructuring covers internal processes, teams, and roles across the company. ## A Company-Wide Workforce Reduction - More than 1,100 employees globally will leave Cloudflare. - The company emphasizes that departures are not judgments about employees’ talent or performance. - Founders Matthew Prince and Michelle Zatlyn are communicating the decision directly rather than routing notices through managers. - Every employee is receiving an email explaining how the changes affect them. ## Severance and Treatment of Departing Employees - Departing employees will receive the equivalent of their full base salary through the end of 2026. - U.S. healthcare support will continue through the end of 2026. - Equity will continue vesting through August 15. - Employees who had not reached their one-year vesting cliffs will receive prorated vesting through August. - Cloudflare frames these benefits as an effort to treat departing employees with empathy and exceed typical industry standards. ## Why Cloudflare Chose Decisive Action - Leadership argues that smaller, repeated layoffs or a prolonged reorganization would create continuing emotional uncertainty. - Completing the changes at once is intended to provide clarity to departing employees and stability for those who remain. - Cloudflare believes its original cloud-native structure helped it surpass older companies with slower systems and processes. - As the company has grown, it says it must avoid relying on organizational structures that worked in the past. ## Looking Ahead - Cloudflare expects the reshaped organization to operate more quickly and innovate more effectively. - The founders planned to discuss the announcement during the company’s earnings call and an all-hands meeting. - They presented the restructuring as necessary to continue advancing Cloudflare’s mission of building a better Internet. The practical conclusion is that Cloudflare is making a large, one-time organizational reset to align its workforce with AI-driven operations, while offering unusually extensive severance intended to reduce the disruption for affected employees.

Read original(opens in new tab)
line3 min readCurated summary

ODW #5: Building a RAG System with a Vector DB and Agent Skills

The workshop demonstrated how a lightweight RAG system can make large collections of technical documentation easier for developers and AI agents to use. Using ChromaDB, Swift Evolution proposals were indexed locally and exposed to Claude Code through MCP. Agent skills then simplified searches by teaching the agent which collection, metadata, and query practices to use. The approach improves document discovery and can support code generation and review. ## Why RAG Is Needed - Large application teams maintain extensive documentation and architectural guidelines. - Developers often spend significant time searching for information about: - Introducing dependencies - Resolving build errors - Following architectural rules - Asking experts can solve problems, but consumes time for both the questioner and the responder. - RAG provides AI agents with structured, searchable knowledge so they can answer questions more accurately using internal documents. ## Building a RAG System with ChromaDB - The workshop used ChromaDB, an open-source local vector database with Python and JavaScript client libraries. - Swift Evolution proposals served as the sample dataset: - Approximately 500 Markdown documents - Consistent structure and proposal IDs such as `SE-0400` - Metadata including implementation status and authors - Participants indexed the documents locally and connected the database to Claude Code through an MCP tool. - This allowed the coding agent to retrieve and reference Swift language proposals during conversations. ## Improving Search with Agent Skills - MCP exposes the available database tools, but the agent still needs to know: - Which collection contains the relevant data - Which metadata fields are useful - How to formulate effective queries - A dedicated `searching-swift-evolution` skill encoded this knowledge, including: - The `swift-evolution` collection name - Proposal ID formats such as `SE-0255` and `ST-0001` - Metadata such as `Status` and `Authors` - A recommendation to query in English - With the skill, users could issue simple requests such as “Investigate SE-0500” without explaining the database structure or MCP workflow. - The workshop also covered skill mechanics, authoring best practices, and practical skill development. - Participants later indexed their own Markdown documents, created search skills, and learned how to deploy the database to LY Corporation’s internal Flava cloud for sharing. ## Potential Applications - Natural-language document search can make internal technical knowledge significantly more accessible. - Coding agents can retrieve relevant documentation automatically before: - Generating code - Reviewing code - Checking compliance with architectural or implementation guidelines - Combining RAG with agent skills or Claude Code sub-agents can embed organizational knowledge directly into development workflows. ## Workshop Design and Results - The online workshop used demonstrations by instructors and mock participants. - More than 1,000 people attended. - Its structure balanced lectures and hands-on exercises: - Lectures explained the core concepts concisely. - Practical demonstrations showed how to apply the system to real work documents. - This balance helped participants understand both the underlying ideas and their practical use. Overall, the workshop showed that a local vector database plus MCP and well-designed agent skills can provide a simple, effective foundation for searchable engineering knowledge and AI-assisted development.

Read original(opens in new tab)
github3 min readCurated summary

Validating agentic behavior when “correct” isn’t deterministic

Agentic systems such as GitHub Copilot cloud agent can complete tasks through multiple valid action sequences, making traditional deterministic tests unreliable. Timing changes, loading screens, and UI differences often produce false negatives even when the agent achieves the correct result. The post proposes an independent “Trust Layer” that validates essential outcomes and convergent behavior rather than rigid step-by-step execution paths. ## Challenges of Agent-Driven Validation - An agent may adapt to network delays or changing UI conditions and still complete its task successfully. - Conventional CI tests can fail when execution no longer matches a recorded script or expected assertion timing. - This creates a trust gap: - **False negatives:** successful tasks are reported as failures. - **Fragile infrastructure:** rendering, timing, and environment noise affect test results. - **Compliance trap:** valid behavioral variation is mistaken for regression. - Agent correctness should focus on reliably achieving essential outcomes, not reproducing an identical sequence of actions. ## Why Traditional Testing Breaks Down - **Assertion-based tests** require manually specifying every expected check and often omit valid alternative paths. - **Record-and-replay tools** are highly sensitive to timing and rendering differences. - **Visual regression tests** compare screenshots without understanding semantic meaning or the broader workflow. - **ML-based oracles** need large training datasets and generally provide little explanation for their decisions. - All four approaches assume correctness means following a stable sequence of observable states, which does not fit autonomous agents. ## Essential, Optional, and Convergent Behavior The proposed approach distinguishes between behavior that determines success and behavior that merely reflects environmental variation: - **Essential states:** Required milestones, such as reaching a VS Code “Search Results” screen. - **Optional variations:** Incidental states, including loading spinners or decorative UI changes. - **Convergent paths:** Different action sequences—such as using a keyboard shortcut or a menu—that eventually reach the same result. - A loading screen may appear in one run and not another, but the appearance of search results is what establishes success. ## Dominator Analysis The post connects this model to **dominator relationships** from compiler theory: - In a control-flow graph, node A dominates node B when every path to B must pass through A. - Applying dominator analysis to agent execution traces can identify: - Mandatory states - Optional states - Points where different execution paths converge - This produces a minimal and explainable definition of correctness instead of relying on every recorded step. ## Graph-Based Execution Modeling - Agent behavior should be represented as a graph rather than a linear script. - Graphs capture branching paths, optional states, and convergence points. - This structure provides a foundation for lightweight, explainable validation in GitHub Actions and other CI environments. A reliable validation system for agents should test whether essential outcomes occurred and whether critical invariants held, while ignoring harmless differences in timing, rendering, and execution order. This outcome-oriented Trust Layer can reduce false failures and make agentic workflows more dependable in production CI pipelines.

Read original(opens in new tab)