Model Context Protocol

97 posts

dropbox3 min readCurated summary

How our universal content processing platform Riviera evolved for AI and beyond

Riviera evolved from Dropbox’s preview-generation service into a shared content-processing platform used by products including Search, Replay, Sign, and Dash. Its core insight was to compose reusable transformations rather than build separate pipelines for every file type and output. As AI increased demand for consistent document extraction and preparation, Dropbox expanded Riviera’s capabilities and began offering them through APIs and Model Context Protocol tools. ## The Preview Problem - Dropbox supports more than 300 file formats, each requiring outputs such as: - Thumbnails - Full previews - Extracted text - Streaming manifests - Metadata - Building a separate service for every format and output would duplicate logic, dependencies, and operational work. - Configurations and package versions could drift across services, making the system harder to maintain and scale. ## Reusable Transformations as the Foundation - Riviera treats previews as sequences of smaller, reusable transformations. - For example, a PowerPoint preview can be produced by: - Converting the presentation to PDF - Rendering each PDF page as an image - The same PDF-to-image transformation can support PDFs and other workflows requiring page images. - This approach enables new formats and products to reuse existing capabilities instead of starting from scratch. ## Separating Coordination from Execution - Riviera uses a central coordinator to: - Collect and validate requests - Compose transformation workflows - Cache responses - Dispatch jobs to backend workers - Each worker handles a specific transformation, creating a clear unit for maintenance and scaling. - The platform now includes more than 100 capabilities and performs hundreds of thousands of transformations per second. - New formats and transformations can generally be added as plugins without changing the core system. ## From Internal Service to Shared Platform - Other Dropbox teams quickly adopted Riviera when they discovered overlapping content-processing needs. - Machine learning teams reused preview thumbnails for image normalization, avoiding duplicate generation. - Search used Riviera to prepare documents for indexing, while Sign, DocSend, and Replay reused existing transformations. - Dropbox eventually opened the plugin model to product teams, allowing them to add capabilities while the Riviera team maintained the platform’s core architecture. - Replay particularly benefited from Riviera’s complex video transcoding and manipulation capabilities, accelerating product development from months to weeks. ## Supporting AI Workloads - Dash introduced greater demand for reliable document preparation before AI processing. - AI systems require content to be transformed into consistent, machine-readable representations, including: - Extracted text - Data from scanned pages - File metadata - Normalized versions of hundreds of file types - These are fundamentally content-transformation challenges rather than AI-model challenges. - Because Riviera already supported many formats and transformations, Dash could build on existing infrastructure instead of creating a separate document-processing system. ## Broader Availability - Dropbox is making Riviera’s capabilities available to external developers and design partners. - Access is provided through APIs and Model Context Protocol tools. - The platform is intended for applications such as content management, document automation, search indexing, and AI document processing. Riviera’s evolution demonstrates the value of a shared transformation platform: reusable workers reduce duplication, centralized coordination improves reliability, and each new capability benefits multiple products. For teams building content-heavy or AI-powered applications, using standardized transformation infrastructure can be more efficient than maintaining format-specific pipelines independently.

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

GitLab 19.2 release notes | GitLab Docs

GitLab 19.2, released July 16, 2026, focuses heavily on AI-assisted development, workflow automation, and centralized security controls. Major additions include the generally available GitLab Duo CLI and custom flows, scheduled pipeline execution policies, and Agentic Chat integrations. Several security features remain in beta, including automated dependency remediation and vulnerability tracking on non-default branches. ## AI-Assisted Development - **GitLab Duo CLI is generally available** for Premium and Ultimate users across GitLab.com, Self-Managed, and Dedicated. - Provides interactive chat and headless CI/CD modes. - Understands GitLab projects, pipelines, and agent configurations. - Supports model selection, shared sessions, tool approvals, MCP connections, slash commands, skills, and `AGENTS.md`. - Can be installed through `glab` or as a standalone tool. - **Custom flows are generally available** across all tiers. - Define reusable, YAML-based workflows for complex multi-step tasks. - Support multi-agent orchestration and human approval checkpoints. - Trigger from mentions, assignments, pipelines, and merge request events. - Offer project or AI Catalog management, visibility controls, secure service-account execution, and YAML validation. - **Foundational flows can now start from Agentic Chat.** - Developer Flow can implement changes or open merge requests. - Code Review Flow can review merge requests. - Fix CI/CD Pipeline Flow can diagnose and repair failed pipelines. - Users approve the handoff and monitor progress in chat or under AI sessions. ## Centralized Pipeline Automation - **Scheduled pipeline execution policies are generally available for Ultimate.** - Define schedules centrally in a security policy project. - Apply them across projects without modifying each project’s `.gitlab-ci.yml`. - Run compliance scripts, security scans, and other jobs independently of commit activity. - Support daily, weekly, or monthly schedules, time zones, time windows, and branch targeting. - Each policy creates a separate pipeline. ## Dependency and Vulnerability Management - **Dependency scanning auto-remediation is in beta.** - Automatically opens merge requests for vulnerable dependency upgrades. - Defaults to patch and minor version updates. - Agentic Breaking Change Resolution can address failed pipelines caused by complex or major upgrades. - GitLab Duo analyzes errors, changelogs, and code usage, commits fixes to the same merge request, and reruns the pipeline. - The feature creates an end-to-end remediation loop, from vulnerability detection through upgrade and repair. - **Non-default branch vulnerability tracking is in beta.** - Supports long-lived branches such as `project-qa`, `project-prod`, `project-iOS`, and `project-android`. - Allows branch-specific filtering in vulnerability reports and dashboards. - Tracks all vulnerability types, including CVEs. - Preserves vulnerability metadata when branches merge into the default branch. - Allows up to twice as many tracked branches as projects in the namespace. ## Governance and Administration - **Selective GitLab Duo availability is available for GitLab Dedicated and Dedicated for Government.** - Administrators can lock selected subgroups and descendants into an “Always off” state. - Other subgroups can retain the option to enable Duo according to their permissions. - The model provides a per-subgroup allowlist rather than disabling AI for the entire instance. - Owners receive clear messaging when a parent group has disabled the features. ## Contributor Recognition - GitLab recognized **vivekshukl007** as the month’s Notable Contributor. - Their contribution added Scala language support to GitLab Orbit, improving code graph capabilities for Scala projects. GitLab 19.2 is especially valuable for teams adopting AI-driven development and centralized security automation. Organizations should evaluate Duo CLI and custom flows for productivity gains, while testing the dependency remediation and non-default branch features carefully because they remain in beta.

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)
aws4 min readCurated summary

AWS Weekly Roundup: AWS Builder Center at 1 year, Network Scanning in Security Hub, Loom for AWS, and more (July 13, 2026) | Amazon Web Services

AWS’s weekly roundup highlights the first anniversary of AWS Builder Center and its expansion into a broader learning and experimentation ecosystem. It also introduces major security, AI, container, database, and developer-tool updates, including internet reachability scanning, Azure support in Security Hub, Hugging Face integration with SageMaker, lower GPU management fees, and Aurora DSQL change data capture. The overall direction is toward more integrated, governed, and accessible cloud development workflows. ## AWS Builder Center Turns One - Launched on July 9, 2025, Builder Center has expanded from a community hub into an ecosystem with: - Sandbox environments - Workshops and the Builders’ Library - Community Spaces, profiles, badges, and streaks - AWS regional capability listings - Saved items, article series, availability notifications, and GitHub/Amazon sign-in - In its first year: - 5,548 authors published 6,448 articles. - Articles received more than 10.4 million page views. - Builders earned 99,226 badges. - The community submitted 565 feature wishes, with 10 already delivered. - The most popular articles covered MCP and Strands Agents, Linux migration with Kiro, and multimodal AI for neurological screening. ## Free AWS Sandbox Environments - Builder Center now offers free, pre-provisioned AWS accounts for workshop exercises. - Each sandbox: - Remains active for eight hours. - Automatically removes the account and resources afterward. - Requires no personal AWS account, credit card, or manual cleanup. - Users can have one active sandbox and request one sandbox per week. ## Security Hub Adds Network and Azure Coverage - Security Hub Network Scanning probes AWS and Azure environments from the public internet. - It identifies: - Public IP addresses, virtual machines, and load balancers. - Reachable ports. - Services operating behind those ports. - Each reachable port produces a finding, which Security Hub Exposures correlates with other configuration and security findings. - Existing customers can enable the feature by account, Region, or organization policy; it is enabled by default for new customers. - Network Scanning is included with Security Hub Essentials at no extra cost. - Security Hub also now evaluates Azure VMs, container images, Function Apps, and identities for vulnerabilities, misconfigurations, and internet exposure. ## SageMaker Studio and Hugging Face Integration - Users can deploy or customize supported Hugging Face models in SageMaker Studio with one click. - New customers receive automatically configured Studio environments for: - Fine-tuning and reinforcement learning with custom reward functions. - Model evaluation. - Deployment to SageMaker or Bedrock endpoints. - Verified customers receive default GPU access to G5, G6, and G4dn instances, while quota usage is visible in Studio. ## Lower GPU Management Fees - Starting July 1, 2026, EKS Auto Mode and ECS Managed Instances reduced accelerated-instance management fees: - G-series: 35% reduction. - P-series and Trainium: 60% reduction. - Existing customers receive the reductions automatically. - EKS adds accelerator-aware node repair and parallel image pulling. - ECS provides GPU metrics through CloudWatch Container Insights and monitors GPU hardware health. ## Aurora DSQL Change Data Capture - Aurora DSQL CDC is generally available and streams insert, update, and delete events to Kinesis Data Streams. - The events can synchronize microservices, invoke Lambda functions, or feed S3, Redshift, and OpenSearch through Firehose. - CDC is designed to avoid database performance impact and requires no infrastructure management. ## Tools for Governed AI Agents - Loom for AWS is an open-source platform for deploying and managing Strands Agents on Bedrock AgentCore Runtime. - It includes: - Identity-provider integration and RBAC/ABAC. - Lifecycle management for agents, memory, MCP servers, and agent-to-agent connections. - Automated tagging for cost attribution. - Agent Registry integration and human approval for sensitive actions. - The Claude apps gateway provides centralized access, policy, and spending controls for Claude Code and Claude Desktop. - It supports OIDC identity providers, per-user and per-group spending caps, managed request settings, and routing through Amazon Bedrock or Claude Platform on AWS. - AWS MCP Server now supports browser-based OAuth using AWS Console or CLI credentials, including IAM federation and IAM Identity Center, with short-lived tokens and automatic refresh. AWS’s updates favor managed services that reduce operational work while strengthening security and governance. Teams should evaluate Builder Center sandboxes for training, enable Security Hub’s broader scanning where appropriate, and consider the new AI-agent controls and managed GPU options for production workloads.

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

Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402

Cloudflare is introducing the Monetization Gateway, which will let customers charge for web pages, datasets, APIs, and MCP tools protected by Cloudflare. It combines payment rules, access control, metering, and payment verification at the edge, initially using stablecoins through the x402 protocol. The goal is to make low-cost, usage-based payments practical for AI agents without requiring sellers to build billing infrastructure or onboard every buyer. ## The Web’s Shift Toward Usage-Based Payments - The traditional web monetized human attention through advertising, subscriptions, and e-commerce. - AI agents consume resources without viewing ads or maintaining subscriptions, creating a need for pricing based on actual usage. - Potential models include: - Charging a few cents per search. - Combining a base fee with usage charges, such as per megabyte uploaded. - Charging only when an outcome succeeds, such as a resolved support escalation. - Agents may generate thousands of requests and micropayments, making per-request, per-token, or outcome-based pricing more appropriate than monthly or per-seat plans. - Existing usage billing has generally required API keys, known customers, extensive accounting systems, and costly payment infrastructure. - Stablecoins such as USDC and Open USD can support sub-cent payments with low fees and settlement times under a second. ## Cloudflare’s Role in Usage-Based Billing - Cloudflare can use its position as a proxy between buyers and sellers to combine payment verification with the request path. - Metering, payment exchange, and settlement can occur away from the customer’s origin. - Customers retain control over: - Pricing. - Access rules. - Revenue. - Sellers will not need to onboard each buyer or build a complete billing system; they can define rules that determine when agents must pay. ## How x402 Payments Work - x402 uses HTTP’s `402 Payment Required` status code to add payments directly to ordinary web requests. - The flow is: - A client requests a protected resource. - The server returns a 402 response containing the price, accepted asset, and payment destination. - The client pays and retries the request with proof of payment. - A facilitator verifies the payment. - The server returns the requested resource. - There are no checkout redirects or separate payment APIs. - Payments settle peer-to-peer directly into the seller’s wallet. - x402 is well suited to machine payments because: - It supports very small transactions. - Buyers do not need an account with the seller. - The payment itself acts as the access credential. - Stablecoins offer fast settlement, low fees, and no chargebacks. ## Monetization Gateway Capabilities - Customers will define payment policies through a dedicated rules API using expressions similar to other Cloudflare rules. - The system will apply to traffic such as tokens, APIs, MCP tool calls, and datasets. - Enforcement will run across Cloudflare’s network in more than 330 cities, allowing payment handshakes to occur near buyers while reducing latency and protecting origins. - Planned functionality includes charging for specific REST methods and routes, such as requiring $0.01 for each `GET` or `POST` request to `/api/premium/*`. - The gateway is also intended to support variable pricing for tasks with different costs. Cloudflare’s approach is to make micropayments a native part of HTTP access, enabling businesses to charge agents directly for the resources they consume without constructing their own payment and accounting systems.

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

From Prompting to Workflows: Boosting Frontend Development Productivity with AI

Frontend development is increasingly shifting from a coding problem to an orchestration problem. Requirements, designs, documentation, discussions, and existing code are scattered across tools, while LLMs can now connect these sources through repeatable workflows. The article argues that structured, reviewable workflows—rather than clever one-off prompts—are the key to scaling AI-assisted development and improving implementation quality. ## From Prompting to Repeatable Workflows - A prompt may produce a useful result once, but it does not create a reusable process. - A workflow defines a repeatable path from inputs to outputs: - Collect context from Jira, Confluence, Slack, and the codebase. - Summarize the actual requirements. - Identify ambiguities and unresolved decisions. - Propose an implementation plan. - Wait for human review before modifying code. - The LLM acts as the engine executing the workflow. - LY Corporation’s Noah MCP connects systems such as Jira, Confluence, Slack, and GitHub, allowing AI agents to access real organizational context instead of relying on manually copied prompts. - Once established, the same workflow pattern can be applied across many tickets, even when the specific inputs differ. ## Example: Planning a List Page The example Jira ticket requests a list page with search, filtering, sorting, and role-based filter visibility. - In the traditional process, a developer manually: - Reads the Jira ticket and identifies missing details. - Searches Figma for loading, empty, and no-results states. - Finds role-based filter rules in Confluence. - Searches Slack for prior decisions. - Inspects the codebase for reusable hooks and components. - Copies findings into notes and assembles an implementation plan. - Implements the feature, resolves bugs and edge cases, and submits a PR. - An AI workflow performs these steps systematically before coding. - The generated plan identifies: - A new `FeatureListPage` route and `FeatureList` component. - Reuse of `useTableFilters` and `useUrlState`. - Existing API support through `GET /api/<feature>`. - URL synchronization for filters, sorting, and pagination. - Role-based visibility using `useCurrentUserRole()`. - Required loading, empty, and no-results states. ## Surfacing Hidden Requirements The workflow improves quality by exposing information that might otherwise appear late in development. - A Slack decision establishes that filter and sort state should use URL parameters rather than `localStorage`, enabling shareable and reloadable views. - Existing hooks such as `useTableFilters` and `useUrlState` are discovered before new code is written, preventing unnecessary duplication. - Unresolved questions are explicitly listed for human review, including: - Whether filter and sort state belongs in URL parameters or `localStorage`. - Which empty-state design should be used when Figma contains multiple variants. - Resolving these questions early reduces rework during implementation or PR review. ## Closed-Loop Verification The workflow should continue after coding rather than stopping when the first implementation is complete. - The agent compares the implementation with the original plan. - It runs: - Type checks. - Linting. - Related unit tests. - Relevant smoke tests or local verification flows. - It reports: - Successful checks. - Failures that were fixed. - Items that could not be verified automatically. - UI screenshots or state notes. - Remaining risks before opening a PR. - This creates a closed-loop development cycle in which AI not only writes code but also validates its work against the intended requirements. Teams should treat AI as a workflow and context-orchestration layer, not merely a code generator. The most effective process gathers information across systems, obtains human approval for the plan, implements with existing project patterns, and automatically verifies the result before review.

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

Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks

GitHub argues that an agentic harness—the system coordinating tools, context, and workflow—strongly influences how effectively an AI model solves software tasks. Its shared Copilot harness aims to match model-vendor harnesses in task completion while using fewer tokens. Benchmark results across four models suggest near-parity overall, with performance varying by model and task. ## Benchmarking Approach - GitHub evaluates the harness using public and internal benchmarks, plus real-world metrics and online experiments. - Comparisons hold the following constant: - The same underlying model - The same task - Context-window size - Reasoning effort - Tool selection - MCP servers - Copilot CLI is compared with: - Claude Code for Claude Sonnet 4.6 and Claude Opus 4.7 - Codex CLI for GPT-5.4 and GPT-5.5 - Benchmarks include: - **SWE-bench Verified:** 500 human-validated Python bug fixes - **SWE-bench Pro:** More complex, multi-step engineering tasks - **SkillsBench:** Skill usage and triggering - **TerminalBench:** Command-line workflows - **Win-Hill:** Software tasks in Windows containers ## Token Efficiency - Copilot’s harness generally completes tasks at rates comparable to model-vendor harnesses while consuming fewer tokens. - It performed better across the reported tests for Sonnet 4.6 and Opus 4.7. - For GPT-5.4 and GPT-5.5, Copilot performed better on nearly every benchmark. - The main exception was SWE-bench Verified, where Copilot was 7% worse with GPT-5.4 and 4% worse with GPT-5.5. ## Task Resolution - GitHub emphasizes that lower token use matters only when the agent successfully completes the work. - Overall task-resolution rates were considered on par with vendor harnesses. - Results varied by benchmark: - Copilot generally did better on SWE-bench Pro, especially with GPT models. - It outperformed vendor harnesses on Win-Hill or matched them for every model. - It performed better on TerminalBench with Sonnet and Opus, matched GPT-5.5, and trailed GPT-5.4. - SkillsBench results favored GPT models on Copilot but favored vendor harnesses for Claude models. - Differences are described as statistically comparable because model behavior is stochastic and run-to-run variation can explain many gaps. ## TerminalBench Variance Analysis - GitHub uses TerminalBench 2.0 to study both cost and completion rate over repeated runs. - The preferred outcome is higher resolution with lower cost. - The analysis illustrates that benchmark results should account for variance rather than relying on a single run. - GitHub presents Copilot as equal to or better than the vendor harnesses on this cost-versus-success comparison. The practical conclusion is that harness design is a reusable performance multiplier across Copilot products. GitHub’s results support using its shared harness when developers need broad model choice, efficient token usage, and comparable task-completion performance, while recognizing that the best harness can still vary by model and workload.

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

Google Antigravity agents get full context with GitLab Orbit

Google Antigravity agents can now access GitLab’s broader software lifecycle context through GitLab Orbit, available in the Antigravity MCP Store. Orbit builds a knowledge graph connecting code, projects, dependencies, merge requests, pipelines, users, and vulnerabilities, allowing agents to answer questions that would otherwise require manual research across GitLab. GitLab reports that internally tested agents using Orbit were up to 11 times faster, used 4.5 times fewer tokens, and hallucinated up to 45 times less. ## GitLab Orbit Adds Lifecycle Context - Antigravity agents can normally access files and terminals but lack information about: - Service dependencies - Related vulnerabilities - Merge request history - Code ownership and reviewers - Pipeline performance - Orbit indexes GitLab and exposes its knowledge graph through: - `query_graph` for structured lifecycle queries - `get_graph_schema` for available node types, properties, and relationships - Agents receive typed results through GitLab Orbit’s JSON query DSL. ## Practical Development Use Cases ### Blast radius analysis - Engineers can identify which projects depend on a module before refactoring it. - Agents can also find open merge requests affecting those files and identify their owners. - This reveals conflicts and stakeholders before changes are made. ### Onboarding and codebase exploration - Agents can explain a service’s dependencies, entry points, and recently opened merge requests. - Results can be captured in a persistent Walkthrough Artifact rather than disappearing in chat. - Orbit reindexes changes within minutes, keeping documentation more current than static wikis. ### Live architecture diagrams - Agents can query service dependencies and render them as diagrams using Nano Banana Pro. - Diagrams can be filtered, such as showing only services with unresolved security findings. - Access controls apply to every query, making generated diagrams safe to share. - GitLab is developing similar functionality through its Software Architecture Map. ## Installation Through the MCP Store - Open Antigravity settings and go to the customization tab. - Find the MCP section and select **Add MCP**. - Choose GitLab Orbit and authenticate with GitLab. - No configuration files or terminal commands are required. ## Availability and Technical Details - Orbit uses the same context engine as GitLab Duo Agent Platform. - It supports code indexing for Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, and C#. - Code is indexed from the default branch and refreshed within minutes. - MCP queries consume GitLab Credits, while `get_graph_schema` calls are free. - The feature is available to GitLab Premium and Ultimate customers on GitLab.com. For teams already using GitLab and Google Antigravity, GitLab Orbit provides a governed, current context layer that can make agents more accurate and useful. Teams should enable Orbit for a top-level group and install it through the Antigravity MCP Store, while accounting for GitLab tier requirements and credit usage.

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

Config 2026: New Materials, New Tools and a More Expressive Canvas | Figma Blog

Figma’s Config 2026 focuses on making the canvas a more expressive, collaborative environment where code, motion, shaders, generative plugins, and Weave tools work alongside traditional design layers. The company argues that code is a design material rather than a separate discipline, and that AI should support—rather than replace—human creativity. New features aim to let teams explore ideas faster while keeping design, implementation, and collaboration connected. ## Code Layers on the Canvas - Figma is introducing code layers, allowing any design layer to become an interactive code layer with one click or a prompt. - Teams can duplicate code layers and explore multiple directions side by side, just as they would with design frames. - Code layers support collaborative workflows including riffing, commenting, and iteration within the same Figma file. - Designers can extract code-generated designs back into editable design layers. - When changes are made to the design, a single click updates the corresponding code layer. - Early access is expected to begin in July 2026 through the Figma beta waitlist. ## Motion as a Core Design Material - Figma Motion brings animation directly into Figma Design, reducing the need to move between separate tools. - Its timeline includes keyframes, presets, and other controls for creating motion from scratch or adding animation to existing designs. - The Figma agent can generate an initial motion concept for designers to refine. - Motion can become part of a design system: an animation applied to a component can carry across screens and collaborators’ files. - In Dev Mode, developers can inspect the complete timeline, including timing values, easing curves, and keyframes. - Animation can be copied as CSS, JSON, or React-ready code. - Motion is MCP-compatible, allowing animated frames to be passed directly to coding agents. - Export formats include MP4, WebM, Animated SVG, and GIF, with additional formats planned. ## A More Unbounded Canvas - Figma describes the canvas as more than a place to store work: it is intended to connect ideas, tools, collaborators, and implementation. - The company’s broader Config strategy is to provide composable materials that let users experiment at the speed of their thinking. - Upcoming capabilities include shader fills and effects, generative plugins, Figma Weave tools, and expanded Figma agent functionality. - Figma argues that AI has lowered the barrier to creating, but people—not AI—will raise the creative ceiling through experimentation and bold expression. Figma’s direction is to unify design and development in one collaborative workspace. Designers and developers should use the new materials selectively: code layers for interactive exploration, Motion for reusable animation systems, and the canvas as a shared environment for rapid iteration from concept through implementation.

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

How we built an internal data analytics agent

Qubot is GitHub’s internal, Copilot-powered analytics agent, designed to make warehouse data accessible without requiring an analyst. Employees ask natural-language questions through Slack, VS Code, or the Copilot CLI, while Qubot uses curated context and selects between Kusto and Trino to produce answers. GitHub’s experience shows that structured context is central to improving both accuracy and response speed. ## The Problem Qubot Addresses - Product teams often struggle to identify the right data model, grain, filters, and query. - Limited analyst availability leaves many teams to investigate telemetry independently. - Qubot targets exploratory questions rather than replacing dashboards or formal reporting. - It enables employees to investigate unfamiliar datasets with minimal setup and maintenance. ## Multiple Ways to Ask Questions - **Slack:** Users ask questions in a shared channel, receive answers in threads, and collaborate on follow-up questions. - Each result is saved as a Markdown report in a pull request, allowing users to refine queries or reuse them in dashboards. - **VS Code and Copilot CLI:** Qubot is installed as a plugin and operates alongside other agents, skills, and tools. - Offering both zero-configuration and developer-focused interfaces increased adoption among different user groups. ## A Federated Context Layer Qubot’s context is tailored to GitHub’s warehouse layers: - **Bronze:** Product teams provide telemetry schemas and metadata for raw events. - **Silver:** Data teams maintain query examples, usage guidance, and required filters for conformed data. - **Gold:** Dataset owners contribute business rules and metric definitions. - ETL pipelines add derived metadata and other signals automatically. - Context is fetched at runtime through the GitHub MCP Server. A dedicated context agent standardizes contributions from different teams. It ingests Markdown documentation and repository references, then organizes and normalizes them into a structure that Qubot can use effectively. ## Evaluation Before Deployment Every change to Qubot’s instructions or context layer is tested through an offline evaluation framework. - Test cases contain prompts, expected answers, ground-truth SQL, domains, and difficulty levels. - Automated orchestration launches multiple parallel agent trials using `gh agent-task create`. - Results are saved as JSON and aggregated by completion rate, accuracy, and duration. - Teams compare configurations and detect regressions before releasing changes. ## Choosing Between Kusto and Trino Qubot connects to both query engines through MCP servers: - **Kusto** is used for fast exploration of recent event data. - **Trino** handles complex joins and deeper historical analysis. - Qubot defaults to Kusto and switches to Trino when the question requires more advanced or historical querying. - This hides query-engine selection from users. ## Adoption and Lessons Learned - Hundreds of GitHub employees have run thousands of queries through Qubot. - Routine questions in analytics support channels declined as teams gained more autonomy. - The agent helped employees who previously avoided the warehouse access data for decision-making. - GitHub found that well-structured, carefully maintained context improved accuracy and made Qubot approximately three times faster at finding the right answer. The main recommendation is to treat analytics context as a maintained engineering asset. A capable agent depends not only on model intelligence, but also on accurate metadata, documented business rules, evaluation-driven iteration, and interfaces that fit users’ existing workflows.

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

Going Beyond Expertise

Technical Writers (TWs) can contribute far beyond writing documentation: they can lead product teams and build systems that turn knowledge into an organizational asset. Toss’s Knowledge System Team created “todoc,” an internal platform that makes documentation easier to write, centralizes scattered knowledge, and enables AI access. Its broader goal is to make documentation emerge naturally from daily work and remain accurate without constant manual maintenance. ## TWs as Product Owners and Makers - The author leads a product team of developers, designers, and TWs. - Their responsibilities include: - Setting product direction, roadmap, and priorities - Interviewing users and bringing insights to the team - Planning features - Building features directly with AI tools - TW expertise is especially valuable because TWs have deeply considered: - Why documents are difficult to read - What makes documentation effective - How information should be structured for AI consumption ## Why Toss Built Todoc Todoc was launched to address weaknesses in Toss’s existing documentation environment. - Static-site-generated documentation required users to: - Clone a repository - Write Markdown - Submit pull requests - Wait for review - This workflow was familiar to developers but created major barriers for designers, PMs, and other non-developers. - Existing documentation tools accumulated outdated policies, unfinished notes, and unexplained content, creating “documentation debt.” - Knowledge was fragmented across: - Static sites - Documentation tools - Code - Collaboration messengers - Individual employees’ knowledge After its beta launch, Todoc grew to more than 500 documents and 40,000 valid pages, with over 1,000 monthly users. ## Todoc’s Four Core Values ### Easy Documentation for Everyone - Anyone can create or edit documents immediately. - Content can be connected from GitHub, documentation tools, internal messengers, and other sources. - The platform removes the technical and procedural barriers to documentation. ### AI-Ready Knowledge - Well-organized documentation can be used by team bots and other AI tools. - Todoc supports API, CLI, and MCP access. - Teams use it for request bots, product specifications, and other workflows. ### A Single Source of Truth - Todoc consolidates scattered sources into complete, centralized documents. - Users can determine which information is current without searching across multiple systems. - The platform serves as the organization’s SSoT (Single Source of Truth). ### Scalable Infrastructure - Teams no longer need to select, build, or maintain their own documentation infrastructure. - Each team can have its own space on a shared platform. - The model is being expanded to Toss affiliates. ## Automating Documentation Quality and Maintenance Lowering the barrier to writing creates a new challenge: maintaining quality. - TW judgment is being converted into: - AI proofreading - Automated document reviews - Bots that generate initial drafts - Todoc is also designed to create documentation automatically from: - Decisions and discussions in internal messengers - Code changes - Ongoing project conversations - The system aims to update documents without relying on someone remembering to maintain them. - It evaluates whether knowledge is still valid by checking: - Whether policies match implemented code - Whether information is actively used - How recently it was updated ## The Evolution of TW Expertise The role is shifting from writing excellent documents manually to designing systems that consistently produce and maintain excellent documentation. - Experience understanding why documents are hard to read becomes standards for human- and AI-readable content. - Judgments about what makes a good document become criteria for AI review and automated editing. - Expertise in identifying outdated information becomes a system for validating knowledge. - TWs increasingly focus on: - Creating places where knowledge can gather - Defining quality standards - Encoding human judgment into systems - Generating documentation through normal work - Keeping knowledge continuously updated The practical vision is an organization where outdated documents trigger their own notifications, project work leaves behind organized records, and recurring explanations are preserved for future employees. Toss’s Technical Writing Chapter is therefore working to systematize TW expertise and establish documentation governance so teams can document effectively without constant manual intervention.

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

Getting more from each token: How Copilot improves context handling and model routing

GitHub is improving Copilot’s efficiency by optimizing both how context is handled and which model performs each task. Prompt caching and deferred tool loading reduce repeated overhead in long agentic sessions, while Auto selects models based on task complexity and real-time system conditions. The goal is to preserve quality while using tokens, compute, and cost more intelligently. ## Prompt Caching and Deferred Tools - Copilot sessions repeatedly include instructions, repository context, conversation history, tool definitions, and task state. - Prompt caching allows repeated prompt prefixes to reuse model state instead of being recomputed on every request. - Tool search loads tool definitions only when needed, rather than placing every full schema into context on every turn. - This is especially valuable for sessions involving MCP tools, terminal commands, file operations, workspace search, and other actions. - The approach reduces fixed per-turn overhead while preserving access to a broad toolset. ## Auto Model Selection - Copilot Auto chooses a model based on the task rather than requiring developers to select one manually. - Quick explanations, focused edits, and complex multi-file changes often benefit from different levels of reasoning. - Evaluations found that no single model consistently performs best across all tasks. - Auto uses more efficient models when they can achieve comparable results and selects stronger reasoning models when the task demands them. - The objective is not simply lower cost, but matching model capability to the work. ## How Auto Routes Tasks Auto combines two signals: - **Real-time model health** - Considers availability, utilization, response speed, error rates, and cost. - Avoids selecting a model that is technically capable but currently overloaded or unreliable. - **Task-aware routing with HyDRA** - Evaluates reasoning depth, code complexity, debugging difficulty, and tool-orchestration requirements. - Identifies models capable of meeting the task’s quality threshold, then chooses the best fit among them. - The system can be tuned toward maximum quality or greater cost savings. ## Cache-Aware Routing - Switching models during every turn can reduce efficiency by invalidating cached prompt prefixes. - Auto therefore keeps the same model during a conversation so the cache can continue building. - It changes models at natural cache boundaries: - The first turn, when no cache exists yet. - After context compaction, when older turns are summarized and the prompt prefix resets. ## Multilingual Routing - Copilot’s routing system was trained on conversations spanning 16 language families, including CJK and European languages. - Evaluations covered production VS Code chat data across 19 languages. - Routing accuracy remained within four points of the English baseline across language groups. - No statistically significant quality gap was observed between the language groups. Copilot’s efficiency strategy combines smarter context management with adaptive model selection. Caching and on-demand tools reduce repeated work, while cache-aware Auto routing chooses an appropriate model without unnecessarily sacrificing quality or session efficiency.

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

Announcing Web Search on Amazon Bedrock AgentCore: Ground your AI agents in current, accurate web knowledge | Amazon Web Services

Amazon Bedrock AgentCore Web Search is now generally available, giving AI agents access to current, cited web information without sending prompts or queries outside a customer’s AWS environment. Built into AgentCore Gateway through the Model Context Protocol (MCP), it combines Amazon’s web index with structured knowledge graph data to provide relevant snippets, URLs, titles, dates, and verified facts. The service lets developers ground agent responses in up-to-date information without building or managing search infrastructure themselves. ## How Web Search Works - Agents submit natural-language queries through an AgentCore Gateway. - The tool returns: - Relevant web snippets - Source URLs - Page titles - Publication dates - Results are powered by: - Amazon’s web search index - Amazon Knowledge Graph data - The combination of web results and structured facts is intended to improve relevance and accuracy over conventional search alone. - Retrieved information can support both grounded responses and follow-up agent actions. ## Secure, Managed Agent Integration - Web Search is a fully managed connector target for Bedrock AgentCore Gateway. - Customer prompts and retrieval queries remain within the AWS environment rather than being sent to external search API providers. - Developers avoid implementing search integrations and operating related infrastructure. - The service supports enterprise governance requirements and secured data workflows. ## Getting Started - Create or open a Bedrock AgentCore Gateway in the AWS console. - Select: - **MCP** as the target protocol - **Connectors** as the target type - **Web Search** as the preconfigured target - After the Gateway URL is created, interact with the tool using: - API calls - AWS CLI - MCP Python SDK - Strands MCP Client - MCP Inspector - MCP Inspector can be used to connect to the Gateway, enter a query, and run the Web Search tool for testing and debugging. - Web Search can also be added to an existing Gateway. ## Early Customer Use Cases - **Benchling** uses Web Search to combine institutional scientific data with published literature, helping researchers generate more complete answers and hypotheses in a governed environment. - **Gen Digital** uses the tool in Norton Revamp to create current online reputation content based on real-world developments. - Customers highlighted the value of current information, AWS-native security, and keeping search queries within their trusted environment. ## Availability and Pricing - Web Search is generally available in **US East (N. Virginia)**. - It is offered at no additional cost initially. - Customers pay applicable Gateway data transfer charges. - New AWS customers may receive up to $200 in Free Tier credits. Developers can try Web Search through the Amazon Bedrock AgentCore console and consult the Gateway documentation for implementation details.

Read original(opens in new tab)