AI Agents

171 posts

cloudflare2 min readCurated summary

Welcome to Agents Week

The post introduces “Agents Week” by reframing the question from what an Agent Cloud should be to what agents themselves need. Unlike today’s human-oriented cloud and web, an Agent Cloud must provide agent-native primitives while also translating between existing human-designed systems and an emerging agent-shaped web. The week will explore how infrastructure, development, security, organizational access, and web interactions should evolve for agents. ## Why the Existing Cloud Falls Short - Today’s cloud and web assume a human is monitoring and interacting with them. - Interfaces are built around attention, visual dashboards, clicking, reading, and human decision-making. - Agents have different priorities: speed, structure, reliable access, and the ability to operate continuously without fatigue or distraction. ## Two Responsibilities of an Agent Cloud - Build an agent-native foundation with primitives designed for agents from the beginning rather than adapted from human tools. - Serve as a translation layer between: - The existing human-shaped web and infrastructure. - The agent-shaped systems being developed for the future. ## Topics for Agents Week The series will examine: - Storage, compute, and execution primitives required by agents. - An agentic development lifecycle, or “ADLC,” that reduces or removes humans from routine development loops. - Secure ways for employees and agents to access organizational systems of record and perform meaningful work. - The evolution of the agentic web, including discovery, access, and payments. - How humans and agents will work together during the transition to agent-oriented systems. ## Invitation to Ask Agents Directly The post encourages readers to ask their own agents what they need from an Agent Cloud instead of relying only on human assumptions. Suggested areas include cloud infrastructure, development processes, secure enterprise access, and web interactions, with readers invited to share their agents’ responses. In practical terms, designing an Agent Cloud requires starting with agents’ operational needs while supporting compatibility with the human-oriented systems that still dominate today.

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

How to govern agentic AI, MCPs, and AI code assistants

Agentic AI changes software governance because agents can independently modify code, call tools, alter CI/CD configurations, and deploy without line-by-line human review. The central control model must therefore focus on agent identity, permissions, data handling, human approval points, and auditable activity. Organizations should treat agents like privileged users, with consistent policies governing what they can access, which models they may use, and when humans must intervene. ## Why Agentic AI Requires New Governance - Traditional code assistants keep humans involved in accepting or rejecting each suggestion. - Agentic systems can perform multi-step actions autonomously across the software delivery lifecycle. - Governance must answer: - What can the agent access? - What is it authorized to do? - What actions did it take, and can those actions be proven later? - Major organizational concerns include: - Distinguishing AI-generated code from human-written code. - Linking generated code to the business requirement or intent behind it. - Maintaining documentation as AI-generated code scales. - The article cites research showing widespread concern about maintainability, technical debt, and governance challenges. ## Controlling Agents, MCPs, and Tools Permissioning becomes especially important when agents use the Model Context Protocol (MCP) to connect to external tools and data. - A governance model should define: - Which agents and workflows are approved. - Where those agents may operate. - Which models they may use. - Recommended controls include: - **Central agent catalog:** Administrators publish and manage approved agents and flows. - **Composite identity:** Actions should be linked both to the agent and the human who initiated it. - **Tool approval guardrails:** Tools can run autonomously, require human approval, or be blocked. - **Prompt guardrails:** Systems should detect attempts to manipulate agents through untrusted webpages, files, or issue comments. - The objective is a role-based, auditable control plane for agents that is as consistent as existing human access management. ## Data Privacy and Self-Hosted AI Because source code is highly sensitive, organizations should establish clear data-handling policies before broad AI adoption. - Key questions include: - Whether the vendor trains models on company code. - Who owns prompts, inputs, and outputs. - Where subprocessors are located and how changes are communicated. - Self-hosted AI can keep agents and data within infrastructure controlled by the organization, which is particularly important for regulated industries. - Bring-your-own-model capabilities allow administrators to: - Use internally validated models. - Assign different models to specific agent workflows. - Reserve trusted models for sensitive operations while using managed models for lower-risk tasks. ## Defining Human Review Boundaries Governance should not eliminate autonomy; it should deliberately establish where autonomy ends. - **Interactive workflows:** Developers review and approve suggestions directly. - **Headless workflows:** Agents operate in CI/CD or other automated environments, requiring approval before sensitive actions or inspection afterward through audit trails. - Organizations should define approval requirements for: - Code review. - Testing and validation. - Deployment. - Enforcement mechanisms can include: - Merge request approval policies that apply equally to human- and agent-created changes. - Tool-level approval settings. - Scanner and pipeline controls that block changes failing security or quality checks. - An organization-wide AI governance policy is preferable to informal team-by-team practices because it promotes consistency and simplifies auditing. ## Practical Recommendation Treat agentic AI as a privileged software participant: give every agent a controlled identity, least-privilege permissions, approved model and tool access, strong privacy protections, and complete auditability. Keep human approval at security-sensitive decision points, while allowing lower-risk actions to proceed autonomously under enforced policies.

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

How We Secure Figma’s Internal Systems With Agents | Figma Blog

Figma built an AI-powered security agent to reduce the manual work involved in investigating SIEM alerts. What began as a retrieval system for finding similar past incidents evolved into an agent that investigates alerts, queries security data, writes fixes, opens pull requests, and retains useful knowledge. The system reportedly reduced alert time-to-resolution by 71% and changed how security engineers handle on-call work. ## The Challenge of Internal Security Operations - Figma’s infrastructure, SaaS tools, identity systems, and employee devices change constantly. - Panther, Figma’s SIEM, monitors these systems and sends alerts to Slack while creating Asana tickets. - On-call engineers previously spent significant time gathering context: - Comparing alerts with incidents from the previous week - Checking whether an existing pull request addressed the issue - Searching Slack discussions for related investigations - Determining whether an alert was new, recurring, or already understood - Existing agent work focused on securing Figma’s codebase, but the team needed a broader system for the many issues detected by its SIEM. ## The RAG Layer: Giving Alerts Historical Context - Figma first created a retrieval-augmented generation system using: - AWS Bedrock Knowledge Bases - Amazon Kendra - Lambda handlers connected to Panther - Each Panther alert is converted into a standardized searchable document. - The system extracts structured information such as: - IP addresses - Usernames and actors - AWS account IDs from ARNs - Alert type, severity, tags, status, and timestamps - Similar alerts are retrieved semantically using the alert title, typically containing the detection name and actor username. - Searches prioritize: - Recent alerts, since investigation procedures evolve - Alerts containing actual investigation context - Comments from engineers rather than merely closed alerts ## Turning Engineer Comments into Institutional Memory - When an on-call engineer comments in a Slack alert thread, Figma captures that text and attaches it to the original alert. - Asana tickets follow a similar process. - The updated alert document is reindexed with: - The accumulated investigation comments - A `has_investigation_context` flag - Future alerts can retrieve these previous explanations and recommendations. - Engineers do not need to adopt a separate annotation workflow; their normal Slack and Asana comments become reusable knowledge. - Each useful investigation effectively makes subsequent similar alerts faster and less expensive to triage. Figma’s approach demonstrates how security agents can build on existing workflows rather than requiring entirely new ones. Starting with searchable historical context allowed the team to progressively develop a broader agentic system while turning everyday investigative work into persistent operational knowledge.

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

The harness is all you need (mostly)

The post argues that effective AI-assisted development depends less on discovering elaborate prompts, tools, or configurations and more on learning the underlying agent harness. A simple workflow—choose a consistent tool, grant agents autonomy in a safe environment, and prototype before implementing—can produce major productivity gains. The author concludes that the harness is “all you need,” with only a few practical habits required. ## Choose a Tool and Learn the Harness - GitHub Copilot is available through the CLI, Copilot app, VS Code, Visual Studio, JetBrains, and other environments. - Although interfaces differ, these tools increasingly share the same underlying harness and workflow. - Beginners may benefit from starting with the CLI because its text-based interface exposes the agent’s behavior directly. - Learning the harness once makes it easier to work across different Copilot environments. ## Enable Autonomous Agent Operation Safely - “YOLO mode,” also called `/allow-all` or “Allow All,” lets the agent execute commands without requesting approval each time. - Repeated approval prompts slow development and encourage users to approve actions without reading them. - Agents should be given autonomy, but unrestricted execution is risky on local or production systems. - Use isolated environments such as GitHub Codespaces or development containers, especially when working with private organizational data. ## Prototype Before Implementing - AI makes it inexpensive to explore multiple designs before committing to an implementation. - For a date picker, the author recommends generating many HTML mockups at once—for example, 20 variations—to compare layouts and interaction models. - Reviewing prototypes can reveal ideas that are difficult to anticipate from text alone, such as navigating from year to month to day. - Visual and tangible representations help people understand complex concepts faster than dense descriptions. ## Use Visual Models for Non-Visual Work - Prototyping is also useful for backend tasks and API design. - For an analytics-download endpoint, the author suggests asking the agent to create several visual implementation options. - Mermaid diagrams can map out alternatives directly in Markdown. - Exploring these options early exposes requirements and trade-offs, reducing rework and wasted tokens. ## Keep the Model and Reasoning Settings Consistent - The author recommends using a medium-sized model with medium reasoning for most tasks. - Keep the same model and reasoning level throughout a feature, bug fix, or enhancement. - Consistency allows previous conversations to remain cached, reducing token costs on later requests. The practical recommendation is to focus less on collecting AI tools and clever prompts and more on mastering the agent workflow: give it controlled autonomy, prototype alternatives early, and maintain a consistent working context.

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

GitHub Copilot app for Beginners: Getting started

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

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

Claude Opus 5 on GitLab: Reasoning built for the hard tasks

Claude Opus 5 is now available through GitLab Duo Agent Platform for complex, high-stakes engineering tasks. GitLab reports a 93.3% benchmark resolution rate, significantly above Opus 4.8’s 73.0%, while maintaining comparable or better speed. The model is intended for difficult debugging, large refactors, coordinated multi-agent work, and code reviews where correctness matters more than minimizing initial cost. ## Reliable Reasoning for Complex Work - Opus 5 is designed to maintain consistent reasoning across long-running tasks and multiple steps. - It aims to reduce partial patches, failed runs, diagnostic work, and repeated prompting. - In GitLab’s internal evaluation: - Opus 5 completed 100% of the tasks it attempted. - Its verified resolution rate was 93.3%, compared with 73.0% for Opus 4.8. - In one five-file SSO authentication task, Opus 5 implemented the feature, added exported types and configuration fields, committed the changes, and opened a merge request. - The model is also presented as effective for code review, identifying genuine bugs while producing relatively few false positives. ## Coordinating Multiple Agents - Opus 5 can support workflows where several agents work in parallel. - Subagent coordination helps prevent agents from interfering with one another’s changes. - Writer-verifier patterns allow one agent to check another’s output before it is accepted. - GitLab Credits usage caps can limit spending when running multiple parallel agents. ## Speed Alongside Depth - On GitLab’s most difficult benchmark tasks, Opus 5 was faster at the 95th percentile: - 768 seconds for Opus 5 versus 784.98 seconds for Opus 4.8. - 768 seconds versus 982.57 seconds for Sonnet 4.6. - GitLab argues that this combination of speed and reliability produces more predictable completion times for long tasks. ## Choosing the Appropriate Model - Sonnet-class models remain suited to routine development because they are fast, affordable, and dependable. - Opus 5 is recommended for: - Difficult debugging - Large refactors - Complex multi-file features - Decisions where rework would be costly - Model selection is configurable within GitLab, while all models use the same context management, policy controls, and audit trail. ## Availability - Claude Opus 5 is available on GitLab Duo Agent Platform and uses GitLab Credits. - New users can start with a free trial. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included credits. Opus 5 is best viewed as a specialized model for high-complexity work rather than a universal replacement for faster Sonnet-class models. Teams should match the model to task difficulty and use spending limits when scaling autonomous, parallel-agent workflows.

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

How Figma Stays Ahead of Vulnerabilities With Agents | Figma Blog

Figma uses AI agents to prevent, detect, and fix vulnerabilities during code generation, pull-request review, and historical code audits. Its central strategy is a shared security policy combined with continuous measurement of precision and recall. The company began with PR review because developer feedback and replaying known bugs created the fastest improvement loop. ## A Shared Policy Across the Development Lifecycle - The same policy guides agents during: - Code generation - Pull-request review - Full-repository auditing - The policy records: - Trust boundaries - Accepted risks - Security precedents - Improving PR review first helped Figma refine the policy before applying it to other stages. ## Measuring Precision and Recall - **Precision** measures how many reported findings are genuine vulnerabilities; low precision creates false positives. - **Recall** measures how many real vulnerabilities the system detects; low recall creates false negatives. - Figma measures: - Precision through author thumbs-up or thumbs-down feedback on findings. - Recall by replaying the reviewer against commits containing known bugs. - These separate signals allow the team to improve both dimensions rather than optimizing for only one. ## AI-Assisted Pull-Request Review - Every pull request receives an automated review. - Findings are posted directly to the PR, allowing developers to respond and fix issues in context. - Figma currently runs: - Claude Code with Opus 4.8 at extra-high effort - Codex with GPT-5.6 Sol at high effort - The models identify different classes of bugs, so Figma reports a finding if either model detects one. - Reviews cost approximately $0.50 per pull request at the median. The agents have identified both sophisticated and conventional vulnerabilities, including: - A multi-step desktop-client exploit in which an injected sandbox object exposed the host realm’s `Function` constructor and enabled possible code execution. - An insecure direct object reference where an authenticated user could retrieve another organization’s invoice by supplying its ID. ## Building Trust Before Exposing Findings - Figma launched Anthropic’s Claude Code Security Reviewer in August 2025 in shadow mode. - Initial results were strong at reproducing known vulnerability root causes, but only 4 of 27 findings—about 15%—were valid. - The team prioritized precision first because developers quickly lose trust in tools that generate excessive false positives. - Figma set a practical target of at least 70% precision. - Developer-facing comments were withheld until precision exceeded that level over a two-week period without severe false positives. - Security engineers replayed the reviewer across eight weeks of historical pull requests and manually labeled incorrect findings. - Those examples were used to create and refine the shared security policy. ## Continuous Improvement Through Precedents - A **precedent** documents why a finding is valid or invalid in a particular context. - Human feedback and historical vulnerability replays feed back into the policy. - This process lets Figma improve the agent automatically rather than relying only on model changes or one-time prompt tuning. Figma’s approach treats agentic security as an engineering and measurement problem, not simply a matter of asking an AI to scan code. Organizations adopting similar systems should establish feedback loops, measure precision and recall independently, and build developer trust before making automated findings part of everyday development.

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

How to build interactive experiences with canvases

Canvases extend GitHub Copilot beyond text-based conversations by providing shared, interactive workspaces where developers and agents can visualize information and take action together. They are useful for tasks such as triaging issues, exploring code architecture, managing worktrees, and searching organizational knowledge. The article concludes that canvases make AI workflows more engaging, practical, and easier to iterate on. ## How canvases work - Canvas extensions are interactive surfaces within the GitHub Copilot app. - Agents can update the canvas while users interact through clicks, edits, swipes, and other controls. - User actions may be sent back to the agent or handled locally. - Developers create one by running `/create-canvas` in a Copilot agent session and describing the desired interface and capabilities. - Canvases can evolve through follow-up prompts that add features or refine existing behavior. ## Visual issue triage - A card-based interface displays GitHub Issues one at a time. - Users swipe right to ship an issue or left to reject it. - The canvas updates immediately, organizing issues into decision-based categories. - This replaces a slower, text-heavy review process with direct visual interaction. ## Interactive codebase diagrams - A generated diagram represents components of a project as connected nodes. - Users can hover over, drag, and filter elements to explore relationships and architectural layers. - The interface turns static codebase documentation into an explorable model. ## Managing sessions and worktrees - A canvas can display active GitHub Copilot sessions and their associated Git worktrees. - It distinguishes active, stale, and orphaned worktrees. - Cleanup actions are available directly from the interface, reducing manual maintenance. ## Improving agent prompts - The prompt coach reviews previous agent interactions. - It identifies issues such as unclear context, spelling mistakes, and syntax problems. - It suggests ways to make prompts more precise and improve future agent results. ## Finding organizational knowledge - A knowledge finder can search sources such as Slack, Teams, email, and documentation. - It identifies people connected to a file or topic. - Results explain both who has relevant context and where that connection was found, making it easier to locate the right expert. ## Getting started Canvases are best suited to workflows where visual understanding and direct manipulation are more effective than sequential prompts. Developers can try them in the GitHub Copilot app by using `/create-canvas`, then iterating with the agent to build a workspace tailored to their task.

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

AWS Weekly Roundup: One-click Lambda setup prompt, OpenAI GPT-5.6 models on Bedrock, and more (July 20, 2026) | Amazon Web Services

The AWS Weekly Roundup highlights new tools for AI-assisted serverless development, including a one-click Lambda setup prompt that configures coding agents with AWS Serverless skills and MCP. It also covers major service updates such as OpenAI models on Bedrock, faster S3 storage-class transitions, self-managed Lambda code storage, and Cognito password-hash imports. Additional stories include SQS’s 20th anniversary, open agent protocols, DynamoDB bulk operations, and a resolved Cost Explorer billing-data incident. ## One-Click Lambda Setup for Coding Agents - The Lambda console now provides a prompt that configures AI coding agents with: - AWS Serverless skills - The Serverless Model Context Protocol (MCP) server - Embedded serverless best practices - The setup guide supports Claude Code, Kiro, Cursor, GitHub Copilot, Codex, Devin Desktop, and OpenCode. - Developers can copy the setup URL into their preferred agent: ```text fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md ``` - AWS’s Agent Toolkit can also install the AWS MCP Server, providing current AWS knowledge and controlled resource access. ## Major AWS Service Launches - **OpenAI GPT-5.6 models on Amazon Bedrock** - Sol: flagship reasoning - Terra: balanced performance - Luna: faster, lower-cost inference - All are available through Bedrock’s Responses API and its high-performance inference engine. - **Same-day S3 transitions** - Objects can transition to S3 Standard-IA or S3 One Zone-IA on the day they are created. - The previous 30-day minimum retention period in S3 Standard no longer applies. - These classes can reduce storage costs by up to 40% while retaining millisecond access. - Suitable for backups, log analytics, and compliance data that becomes cold quickly. - **Self-managed Lambda code storage** - Lambda can reference code directly from customer-owned S3 buckets. - Lambda no longer needs to create intermediate copies. - This removes code-storage limits and can shorten activation times after deployments. - **Cognito password-hash imports** - CSV user imports can now include password hashes. - Users can sign in immediately with existing credentials instead of resetting passwords. - Import configuration specifies the source system’s hashing algorithm. ## Additional AWS Updates - **Amazon SQS at 20** - SQS continues to provide scalable decoupling between message producers and consumers, two decades after its public launch. - **Open protocols with Strands Agents SDK** - An example demonstrates how MCP, A2A, UTCP, AG-UI, and x402 can work together when building AI agents. - **Open-source DynamoDB Bulk Executor** - Performs large-scale table operations without custom code. - Supports `count`, `find`, `delete`, and `update` commands. - **Kiro CLI for AWS Support** - MCP integration combines investigation, documentation lookup, and support-case creation. - Examples cover Glue failures, Lambda cold starts, and WAF false positives. ## Cost Explorer Incident - Some customers saw inaccurate estimated billing and usage data in Cost Explorer. - The issue generated erroneous budget and cost-anomaly alerts. - AWS resolved the incident and is conducting a retrospective to improve billing-incident prevention and response. AWS’s latest releases emphasize faster serverless development, more capable AI tooling, lower-cost storage, and easier automation of operational tasks. Developers should explore the Lambda agent setup and Agent Toolkit while reviewing the new storage, identity, and bulk-operation capabilities for relevant workloads.

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

GitLab Transcend Hackathon: What developers built on GitLab Orbit

GitLab’s Transcend Hackathon showed how developers use GitLab Orbit’s live code graph to answer questions about dependencies, ownership, testing, deployments, and risk. Of 1,576 registered participants, teams submitted 265 eligible projects, while contributors also merged 61 improvements into Orbit itself. The strongest projects used graph-based context to improve change analysis, migrations, testing, security response, and agent governance. ## Problems Developers Targeted - Around 70 teams built tools to predict what a change might break before merging. - More than 30 focused on onboarding and codebase comprehension. - Other common use cases included: - Incident root-cause analysis - Architecture drift detection - Flaky-pipeline diagnosis - CVE tracing across repositories - The popularity of these projects reflected a shared problem: relevant information is scattered across Git, CI, deployment systems, and dashboards. - Orbit consolidates those relationships into a queryable graph that agents can access through MCP or engineers can query directly. ## Technological Implementation - **Winner: Sankofa** - Provides three agents triggered by different workflow events: - **Radar** analyzes merge-request blast radius, affected pipelines, and ownership. - **Guide** prepares briefs when issues are assigned. - **Shield** traces vulnerabilities through the dependency graph. - Shield can identify a vulnerability’s full reach in one graph traversal. - **Runner-up: Stayed Shipped** - Measures whether changes merged by AI agents remain in production. - Detects changes that were later silently fixed forward, a result standard dashboards often miss. ## Design and Usability - **Winner: Carver** - Estimates the cost and risk of legacy migrations using Orbit’s dependency graph. - Breaks work into units, estimates effort and generation cost, and highlights untested, high-risk services. - Refuses to invent estimates when the relevant service cannot be grounded in Orbit. - **Runner-up: Marshal** - Takes an organization-wide migration goal, identifies affected repositories, sequences the work, and creates merge requests in waves. ## Potential Impact - **Winner: CrossCut** - Selects only tests that a change can actually affect. - Traverses Orbit’s call graph from changed symbols to determine transitive test impact. - Can reduce CI workloads by 90% or more on large or cross-repository suites. - **Runner-up: OrbitWeaver** - Performs autonomous refactoring using exact graph-based blast radius rather than vector similarity. - Updates affected files in dependency order, reducing the risk of incomplete refactors and broken pipelines. ## Quality of the Idea - **Winner: Transcend** - Extends Orbit with OWL, SPARQL, RDF, and semantic-web reasoning. - Supports queries involving transitive closure, external knowledge bases, and complex joins beyond the native API. - Its demonstration connected code implementing knowledge-graph embedding methods with related papers, authors, and publication years. - **Runner-up: Universal Agent OS** - Focuses on agent governance rather than agent capabilities. - Requires agents to interview users, plan before coding, preserve evidence, and validate their work. - Emphasizes accountability as AI-generated code becomes more common. ## Contributions to Orbit - The Contribute Track produced 61 merged merge requests from 26 contributors. - Improvements included: - Support for C++20 concepts, Go package declarations, Kotlin coroutines, and Ruby lambdas - Ontology corrections - A CI SIGPIPE fix - The first Orbit query tutorial - Documentation fixes, including clarification of `max_depth` versus `max_hops` - Nineteen contributors received cash prizes, and all participants earned swag credits. GitLab Orbit’s strongest value is not simply agent orchestration but the structured context behind it. Teams building reliable developer automation should prioritize a live dependency and ownership graph, using precise traversal where correctness matters more than probabilistic retrieval.

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

Automate work item assignment with GitLab Duo

The GitLab Duo Agent Platform’s new **“Work item created”** trigger automates triage as soon as an issue or other work item is created. A custom flow can assess team workloads and assign the item without manual intervention, improving speed and workload balance. The post demonstrates this using two agents and GitLab Orbit. ## The Problem with Manual Assignment - Team members must repeatedly check capacity, workload, meetings, and PTO before routing each work item. - Manual triage becomes slow and inconsistent as issue volume grows. - Previously, GitLab Duo Flows required a human action—such as a mention or assignment—to start. ## How the Trigger Works - The trigger fires immediately when a work item is created in a configured project. - Flows run continuously in the background without requiring someone to initiate them. - This enables instant, scalable routing while developers focus on higher-value decisions. ## Benefits of Automated Triage - Assigns and routes work immediately. - Handles anything from a single issue to hundreds of items. - Applies workload and availability criteria consistently. - Removes repetitive assignment work from team leads and developers. ## Example: The “Work Item Assigner” Flow - The demonstrated flow runs in the `Intra-account-transfers` project. - Its first agent uses GitLab Orbit to determine each resource’s number of open work items across the top-level group. - A second agent identifies the least-loaded person and assigns the new work item to them. - When a new issue is created, the flow activity log shows both agents executing their steps. - In the example, the issue is automatically assigned to William, who has the lightest workload. ## Potential Enhancements - Connect the flow to HR or PTO systems through Model Context Protocol (MCP) to account for upcoming leave. - Integrate team calendars to consider real-time availability when making assignments. The post recommends using the “Work item created” trigger with workload-aware agents to automate routine assignment decisions, achieve faster triage, and distribute work more evenly.

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

Forrester Consulting: GitLab Duo Agent Platform delivers 400% ROI

GitLab-commissioned Forrester research found that organizations using GitLab Duo Agent Platform could achieve a 400% three-year ROI, $7.5 million in net present value, and payback in under six months. The study argues that agentic coding creates the greatest business value when integrated across the software lifecycle—not merely used to generate code. Benefits included faster onboarding, shorter migrations, quicker security remediation, and more developer time for feature work. ## Study Scope and Financial Model - Forrester interviewed four organizations across financial services, software, entertainment, and insurance. - Their experiences were modeled as a composite global company with: - $3 billion in annual revenue - 3,000 employees - GitLab Duo Agent Platform adoption growing from 150 to 250 users - Three-year risk-adjusted costs totaled approximately $1.9 million: - $1.3 million in consumption credits - $589,000 for implementation, training, support, and internal labor - Quantified benefits reached $9.4 million, producing: - 400% ROI - $7.5 million net present value - Payback in less than six months ## Problems Before Adoption - Manual processes and ad-hoc knowledge sharing slowed development. - New developers depended heavily on senior engineers for context and troubleshooting. - Security fixes waited in queues for specialists with the necessary expertise. - Code review was often a larger bottleneck than writing code. - Senior engineers were repeatedly interrupted to unblock other team members. ## Quantified Benefits - **80% faster developer onboarding** - Agentic chat in IDEs and repositories helped new hires understand unfamiliar codebases independently. - Estimated savings: $582,000. - **75% shorter migration timeline** - A migration from on-premises GitLab to GitLab SaaS finished in two months instead of eight. - Agents helped diagnose pipeline failures and resolve issues during the migration. - Estimated labor savings: $157,000. - **40% more time for security and QA engineers** - Contextual explanations and suggested fixes reduced remediation effort and reliance on senior staff. - Estimated three-year savings: $1.3 million. - **20% more developer capacity for feature work** - Agents supported code review, testing, and troubleshooting. - Estimated combined benefit: $7.4 million. - Additional unquantified benefits included reduced need for overlapping AI tools, improved developer satisfaction, and stronger knowledge sharing. ## Broader Impact on Software Delivery The study found that organizations shipped features in days rather than weeks, resolved vulnerabilities more quickly, onboarded staff faster, and compressed major infrastructure work. Its central conclusion is that AI productivity gains compound when agentic coding is connected to infrastructure supporting the entire software delivery lifecycle. The findings are based on interviewed organizations and a composite financial model, so actual results will vary. Companies evaluating agentic development should use the study as a framework for estimating benefits across productivity, security, onboarding, and operational efficiency—not as a guaranteed ROI.

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

Bring GitLab Duo Agent Platform to your terminal

GitLab Duo CLI, generally available in GitLab 19.2, brings GitLab Duo Agentic Chat into the terminal. It combines code assistance with project, pipeline, permissions, and agent context from GitLab, helping developers handle failures and multi-step delivery work without leaving the shell. It supports both interactive development and headless automation in CI jobs and scripts. ## Why Terminal AI Needs GitLab Context - Many delivery problems occur after coding: failed pipelines, broken tests, vulnerabilities, dependency issues, and CI configuration problems. - Generic coding agents lack access to GitLab project context, pipeline data, permissions, and organization-wide agent configuration. - Duo CLI connects terminal work to the broader GitLab software lifecycle and provides centralized administration and identity management. ## Capabilities of Duo CLI - Investigate codebases, refactor, troubleshoot pipelines, improve CI/CD, and complete multi-step tasks from the terminal. - Share conversations across Duo CLI, the GitLab web UI, and editor extensions. - Use **Plan mode** to inspect and prepare changes, then **Build mode** to apply them. - Run `/doctor` to diagnose setup issues and `/mcp` to inspect MCP configuration. - Available on GitLab.com, GitLab Self-Managed, and GitLab Dedicated, with instance-level controls for administrators. ## Interactive and Headless Operation - Launch through the GitLab CLI with `glab duo cli`, which handles authentication, or use the standalone `duo` command with a personal access token. - Interactive mode allows users to chat, review proposed actions, and approve tools before execution. - Headless mode supports automation through commands such as: - `glab duo cli run --goal` - `duo run --goal` - A pipeline failure can be investigated directly from the shell, with Duo CLI analyzing the issue and proposing changes for review. ## Customization and Adoption - Duo CLI follows project instructions in files such as `chat-rules.md`, `AGENTS.md`, and `SKILL.md`. - Custom slash commands can extend interactive workflows. - Users can install and authenticate through the Duo CLI documentation, or begin with `glab duo cli`. - GitLab offers Duo Agent Platform trials and includes credits for eligible Premium and Ultimate subscriptions. Duo CLI is positioned as a way to extend AI assistance beyond code editing into the operational parts of software delivery. Teams can start with interactive troubleshooting and gradually use headless mode for repeatable CI and scripting workflows.

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

Turn multi-step software delivery into agentic flows you can trust

GitLab Duo Agent Platform’s Custom Flows are now generally available, enabling teams to automate multi-step software delivery rather than relying on chat responses, scripts, or manual runbooks. Flows can start from GitLab events or Agentic Chat, execute tasks across projects, and include human approval checkpoints. The goal is dependable, repeatable automation for work such as implementing issues, repairing pipelines, and reviewing merge requests. ## Why Software Delivery Remains Manual - Real development tasks involve multiple steps: gathering context, changing code, opening a merge request, waiting for CI, and responding to reviews. - Without workflows, people must manually coordinate each handoff and remember undocumented team practices. - Teams previously hesitated to formalize these processes because Custom Flows lacked production readiness and sufficient event coverage. ## What Agentic Flows Provide - Automate trusted sequences triggered by events such as: - Mentions and assignments - Pipeline activity - Merge request lifecycle changes - Work item updates - Run under a composite identity, keeping permissions bounded and actions attributable. - Launch specialist workflows from Agentic Chat, including: - Developer Flow for implementing changes - Code Review Flow for reviewing merge requests - Fix CI/CD Pipeline Flow for diagnosing and repairing failures - Require user approval before handing work from chat to a flow, while displaying progress inline. - Use review exclusions to avoid automatically reviewing bot-authored or branch-pattern merge requests. - Apply custom review instructions so automated reviews match team standards. ## Custom Flow Configuration - Create flows from a project or the AI Catalog. - Set visibility, enable flows for selected projects, and attach GitLab event triggers. - Add human-in-the-loop checkpoints for sensitive operations. - GitLab 19.2 adds: - A “work item status changed” trigger - Bulk enablement of public flows across up to 100 projects - A future Flow Creation Agent is planned to generate runnable flow definitions from plain-language descriptions. ## Costs and Adoption - Event-driven flows consume GitLab credits according to the work they perform. - GitLab recommends testing flows in a small number of projects before broad deployment. - Access is available through a GitLab Duo Agent Platform trial or through included credits for Premium and Ultimate subscribers. Teams should begin by encoding a few well-understood delivery processes as Custom Flows, adding approval gates where necessary, and expanding gradually while monitoring credit usage and automation quality.

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

Better tools made Copilot code review worse. Here’s how we actually improved it.

Copilot code review became more expensive and less effective after GitHub replaced its specialized exploration tools with shared `grep`, `glob`, and `view` tools. The tools themselves worked correctly, but their general-purpose instructions encouraged broad repository browsing rather than focused pull request investigation. After rewriting the instructions around diff-first review workflows, GitHub achieved roughly 20% lower average review cost without reducing review quality. ## Why the Tool Migration Regressed - Copilot code review previously used specialized tools for: - Listing directories - Searching files and directories - Reading code - These tools often returned matching lines along with surrounding context, which suited earlier models that made fewer tool calls and needed more context per request. - GitHub migrated to the shared Unix-inspired tools used by Copilot CLI and other products: - `glob` replaced `list_dir` - `grep` replaced `search_file` and `search_dir` - `view` replaced `read_code` - The migration aimed to reduce duplicated implementations and let improvements benefit multiple Copilot products. - Offline benchmarks showed higher review costs and fewer useful comments after the migration. ## Repository Browsing Instead of Pull Request Review - Execution traces showed the agent: - Searching broadly - Guessing file paths - Reading large sections of code - Finding more things to search - Carrying unnecessary context into later reasoning - This workflow is reasonable for a coding assistant asked to understand an unfamiliar repository. - It is inefficient for code review, where the agent should begin with the pull request diff and investigate a specific potential problem. - Excessive tool output increases token usage because returned file contents remain in the agent’s context window. - Broad exploration can also make the review less focused by mixing relevant evidence with unrelated code. ## The Difference Between Coding and Reviewing - A coding assistant may need to map a large area of a repository before editing code safely. - A reviewer typically asks targeted questions based on the diff, such as: - Where is the changed function called? - Is a modified configuration key used elsewhere? - Does a similar test or helper already exist? - What is the smallest code range needed to understand the behavior? - Copilot code review has a narrower objective: - Start from the pull request diff - Determine whether the change introduced a real issue - Gather only the evidence needed to confirm or dismiss that issue - The shared tools were designed for broader interactive workflows, so their instructions unintentionally encouraged the wrong behavior in the review agent. ## Instructions Were the Real Fix - GitHub concluded that changing tools was not enough; the agent’s workflow instructions also had to change. - The revised instructions emphasized: - Diff-first investigation - Targeted searches - Minimal surrounding context - Narrow evidence gathering - Avoiding unnecessary repository-wide exploration - With these workflow changes, the shared tools became more effective for review rather than merely reproducing their coding-assistant behavior. - The result was approximately 20% lower average review cost while preserving review quality. The practical lesson is that tool quality cannot be evaluated separately from the instructions and workflow guiding an agent. Shared tools can work well across products, but each use case needs instructions that match its task—in this case, focused, evidence-driven pull request review rather than broad repository exploration.

Read original(opens in new tab)