AI Agents

171 posts

figma2 min readCurated summary

How Decagon Uses AI For Design System Saturation | Figma Blog

Decagon built its Deco design system to maintain quality and consistency as its AI-powered customer service platform scaled. By connecting Figma, Storybook, coding agents, and Figma MCP, the company reduced design-to-code friction and enabled agents to produce higher-fidelity implementations. The result is a shared design language and a continuous loop between design and engineering. ## Building a Design System for Quality at Scale - Decagon initially had no formal design system, while its product and team were expanding rapidly. - Inconsistencies across the platform weakened the polish expected by enterprise customers. - Designers and engineers created Deco together, addressing implementation details early, including: - Focus-mode behavior - Disabled, read-only, error, and warning states - Placeholder decisions - Existing code patterns and edge cases - Deco grew into an organization-wide Figma library with hundreds of components, styles, and variables. - Library analytics recorded tens of thousands of component insertions in 30 days, indicating broad adoption. - The system provides: - A single source of truth for design and implementation - A shared vocabulary between designers and engineers - Faster screen assembly from reusable components - Greater consistency across teams and product areas ## Connecting Design and Code with Figma MCP - Before MCP, designers exported specifications, developers interpreted them, and discrepancies were discovered during review, creating repeated back-and-forth. - Decagon moved its design-system components into Storybook so engineers and coding agents could work from precise, documented implementations. - The team created coding-agent skills that: - Require agents to use approved design-system components - Help designers add new components while keeping Figma and code aligned - With Figma MCP enabled, agents can access design specifications, code context, and the Figma canvas within the same workflow. - Designers can provide a Figma link to a coding agent, which uses design context and maps the requested interface to Deco components. - This produces high-fidelity starting points and speeds up iteration while reducing divergence between the intended design and the final code. Decagon’s experience suggests that design systems become significantly more valuable when they are connected directly to development tools and AI agents. Maintaining synchronized component libraries across Figma and code can help fast-moving teams scale without sacrificing consistency or implementation quality.

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

Automating cross-repo documentation with GitHub Agentic Workflows

The Aspire team used GitHub Agentic Workflows to automate documentation across its product and documentation repositories. For versions 13.3 and 13.4, the system produced 82 documentation pull requests, typically within 44.8 hours of the corresponding product change, with review from the engineer who shipped the feature. The approach combines AI-generated drafts with deterministic branch selection and tightly controlled write permissions. ## The Cross-Repository Documentation Problem - Product code lives in `microsoft/aspire`, while documentation lives in `microsoft/aspire.dev`. - The old process depended on writers discovering changes weeks later and reconstructing intent from closed pull requests. - Engineers often had limited context by the time clarification was requested. - Broad repository tokens were unacceptable, making secure cross-repository automation difficult. ## How GitHub Agentic Workflows Work - Workflows are authored as Markdown files with YAML-style frontmatter and natural-language instructions. - A compiler generates a standard GitHub Actions `.lock.yml` workflow. - An agent analyzes repository data and produces proposed actions as JSON rather than writing directly to GitHub. - A separate “safe-outputs” handler executes only explicitly permitted actions through a narrowly scoped GitHub App. - This separation provides AI flexibility while preserving security controls and auditability. ## The Automated Documentation Pipeline - The `pr-docs-check.md` workflow runs when a pull request is merged into `main` or a `release/*` branch. - A deterministic Bash script resolves the documentation target branch before the agent runs: - Product pull request milestone, such as `13.4`, maps to `release/13.4`. - Linked issue milestones are checked next. - The pull request’s base branch is used if it matches a release pattern. - Otherwise, documentation targets `main`. - The agent: - Reviews the product diff and linked issues. - Determines whether documentation is necessary. - Checks out `microsoft/aspire.dev`. - Writes documentation using the project’s existing writing conventions and Starlight/MDX components. - The workflow creates a draft documentation pull request with: - A `[docs]` title prefix. - The `docs-from-code` label. - A restricted base branch. - The documentation repository as the target. - The subject-matter expert who reviewed the original product pull request as reviewer. - A comment containing the documentation pull request link is posted back to the source pull request, while older workflow comments are minimized on reruns. ## Security Through Safe Outputs - The agent receives constrained GitHub tools and read access. - Repository access is limited through allowed repositories and a dedicated GitHub App. - Actions must use pinned, integrity-checked components through `min-integrity: approved`. - Write operations are restricted to declared safe outputs, such as creating pull requests. - Documentation changes remain drafts and are never auto-merged. ## Results and Broader Fit - The process eliminated the need for additional staff or major process training. - Documentation drafts arrive shortly after the related code is merged, while the implementation context is still fresh. - The workflow preserves human review by routing drafts to the engineer or SME who approved the feature. - Both the automation documentation and `aspire.dev` use Astro and Starlight, making the tooling and publishing environment closely aligned. The practical recommendation is to use agentic automation for drafting and routing documentation, but keep branch resolution, permissions, and final review deterministic and human-controlled. This provides much of the speed of autonomous workflows without granting an AI agent unrestricted repository write access.

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

How we used AI agents to migrate GitLab rate limiting

GitLab used a three-person engineering pod and AI agents to migrate 121 application-level rate-limit keys into a shared `labkit-ruby` implementation. The migration succeeded because humans retained ownership of architecture, scope, rollout decisions, and final review while agents handled mechanical coding, tests, and reviews. The main lesson was that disciplined workflows and meaningful observability mattered more than the agents themselves. ## Migration Setup - GitLab was consolidating two production rate-limiting systems: - `Gitlab::ApplicationRateLimiter`, with 121 keys - A separate Rack-level implementation - The target was a single observable, testable, and consistently operated implementation in `labkit-ruby`. - A three-person pod divided responsibilities across the monolith, the gem, architecture, and project scope. - AI agents: - Read project context - Drafted specifications - Implemented bounded changes - Wrote tests - Pre-reviewed merge requests - Humans controlled scope, architecture, rollout strategy, and final approvals. ## The Specification and Review Loop - The team followed a repeatable process: - Read the epic - Write a specification - Conduct adversarial review - Implement only after blockers were resolved - Verify with explicit evidence - Review the merge request adversarially - Escalate to human review - Merge - Adversarial review was limited to two resolution rounds before requiring human involvement. - The project produced 14 numbered specifications and more than 30 merge requests. - This structured loop made agents useful on legacy code without allowing them to make high-impact decisions independently. ## Successful Rollouts - The first cohort covered five heavily used keys, including: - `pipelines_create` - `notes_create` - `user_sign_in` - Rollout progressed from 1% to 10%, 50%, and finally 100% over two days. - Engineers compared the old and new implementations during rollout and deliberately generated traffic to test behavior above the configured limits. - The second cohort consolidated 95 call sites: - 83 in the monolith - 12 in Enterprise Edition - Agents were especially effective at this repetitive, large-scale codebase work, avoiding roughly 95 individual feature-flag changes and 190 YAML edits. ## Observability and Shadow-Mode Failure - During Cohort 2, an adapter dropped an identifier on an unauthenticated path by incorrectly packing three strings into two primitive slots. - Some users briefly received generic failures when enforcement began. - Shadow comparison had detected divergence, but the dashboards did not distinguish structural identifier collisions from ordinary disagreements. - The team disabled enforcement immediately and shipped a short-term fix two days later. - The deeper cleanup will replace array-based scopes with named characteristics when calling `ApplicationLimiter`. - The incident showed that having observability is insufficient if it cannot identify the failure modes that require action. ## Missed Rate Limits and Infrastructure Constraints - An audit revealed that the original five-cohort plan had missed 17 of the 121 keys. - The omissions included: - Enterprise-only limits - Registry entries - Webhook keys - `partner_*` sub-second limits - Orphaned adapter rows - The team had not maintained a complete inventory count, making it possible for keys to become effectively invisible. - A sixth cohort was added to cover the missed cases. - Redis capacity also became a constraint: - The rate-limiting service used a four-shard cluster. - `maxclients` was increased incrementally. - Rollout stopped at 75,000 connections rather than 100,000 because primary CPU usage approached saturation. - Redis command execution was limited by one core per primary, leaving no simple vertical scaling solution. ## How AI Changed the Work - Agents made code generation faster, shifting the bottleneck to: - Human review capacity - Rollout judgment - Operational monitoring - Reviewer and operator attention - Agent collaboration was not always efficient; engineers sometimes spent longer guiding agents than they would have spent coding directly. - Engineers also had to develop new skills for specifying, reviewing, and correcting agent-generated work. - Agents could execute a request mechanically—such as creating dozens of feature flags—but could not decide whether that design was appropriate. - Human judgment remained essential for simplifying the rollout and avoiding unnecessary per-key flags. ## Outcome - By mid-June, all six cohorts had reached 100%. - All 121 application rate-limit keys were running through the new framework. - The migration demonstrated that AI agents can safely support complex legacy-system changes when paired with bounded tasks, adversarial review, gradual rollouts, complete inventories, and failure-specific observability. A practical recommendation is to use agents for repetitive implementation and verification, but keep architecture, risk assessment, rollout control, and operational decisions firmly with experienced humans.

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

Your site, your rules: new AI traffic options for all customers

Cloudflare is replacing its broad “Block AI Bots” approach with finer controls based on what automated systems do: Search, Agent, or Training. The goal is to let website owners preserve discoverability and useful automation while blocking uncompensated model training and other unwanted access. These controls will be available to all Cloudflare customers, including Free-tier users. ## Why AI traffic needs more nuance - The traditional crawler exchange—content in return for referrals—has weakened as AI systems increasingly consume content without sending traffic back. - Website owners previously faced a binary choice: - Allow AI access to remain discoverable. - Block automation and protect content at the risk of losing visibility. - This tradeoff particularly harms small sites and can favor established search providers that use the same crawlers for search and training. ## A behavior-based AI taxonomy Cloudflare will classify automated traffic by its purpose rather than simply labeling bots as “AI”: - **Search** - Collects or indexes content to answer future queries. - Builds a database proactively. - Should generally provide referrals or other fair compensation. - **Agent** - Acts in real time on behalf of a person. - Includes chat-fetch bots such as ChatGPT-User and browser-use agents driven by Gemini or Claude. - Visits a site to complete a specific task for a human. - **Training** - Collects content to train or fine-tune a model. - Permanently incorporates data into the model’s underlying architecture. Bots may have multiple classifications. Cloudflare encourages operators to separate Search, Agent, and Training crawlers so site owners can understand and control their access more effectively. ## New controls for AI traffic - Cloudflare is adding separate controls for Search, Agent, and Training traffic. - These options replace the need for a single all-or-nothing AI blocking decision. - The controls will be available to all customers, including those on the Free plan. - Cloudflare will continue tracking other automated behaviors, such as ad verification, feed fetching, and agentic transactions. ## New default rules Starting September 15, 2026: - For new domains, **Training** and **Agent** crawlers will be blocked by default on pages displaying ads. - **Search** crawlers will remain allowed by default because they are more likely to send visitors back. - The policy treats ads as an indication that human attention—and therefore monetizable traffic—is the intended outcome. - Multi-purpose crawlers will be governed by all of their classifications, using the most restrictive applicable rule. - As a result, crawlers such as Googlebot, Applebot, and BingBot may be blocked when customers choose to block Training traffic. - Website owners can opt out of the new defaults through Cloudflare Security settings before September 15. Cloudflare’s recommendation is to manage AI access by behavior: allow Search when referrals matter, permit Agents when real-time user tasks are valuable, and block Training where content reuse is not adequately compensated.

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

Got Skills? Make the Figma Agent a Better Collaborator | Figma Blog

Figma’s custom skills turn team knowledge and workflows into reusable instructions for the Figma agent. They complement design systems by adding guidance such as brand voice, critique methods, writing standards, and review processes. Figma’s experience suggests that any repeated task or team-specific judgment can become a shared skill that improves consistency and collaboration. ## Custom Skills Capture Team Expertise - A skill is a reusable set of plain-English instructions for the Figma agent. - Skills can be triggered in chat with a forward slash (`/`). - Teams and organizations can publish skills so members do not have to recreate prompts or explain workflows repeatedly. - They are particularly useful for practices that are easy to use but difficult to document and often exist only in someone’s head. ## A Second Opinion on Demand Skills can provide focused critique and help teams apply shared standards. - **Simulate stakeholder feedback:** Figma created a skill based on CEO Dylan’s comments, allowing designers to pressure-test work before a review. - **Apply UX writing standards:** A skill based on Figma’s style guide checks capitalization, punctuation, and other consistency issues. - **Review work as a new user:** The agent can assess an experience from a first-time user’s perspective, exposing friction and missing context that experts may overlook. - Design systems supply components, patterns, and UI elements; skills add broader team expertise such as compliance rules, product principles, and critique frameworks. ## Build Once, Use Everywhere Repeated team rituals are strong candidates for automation through skills. - **Catch-me-up:** Summarizes recent file or project activity so returning teammates can quickly understand what happened without searching comment threads. - **Crit preparation:** Interviews the designer about the project, persona, scope, and audience, then creates a critique page with guided discussion prompts. - Figma’s crit-prep skill draws on Nielsen Norman Group best practices to encourage more effective research questions. - **Crit recap:** Organizes feedback into themes, decisions, action items, and deferred items. - Recaps can be placed on the canvas or copied into Slack, helping preserve decisions and keep follow-up work visible. ## Connecting Existing Tools The article begins describing how skills become more powerful when they can draw on the tools a team already uses, suggesting that skills can connect workflows and information across the organization. The provided excerpt ends before giving the specific examples or implementation details. Teams should start by identifying repeated tasks, recurring meetings, or expert review processes and turn those into shared slash-command skills.

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

Claude Sonnet 5 on GitLab: More reliable, more efficient

Claude Sonnet 5 is now available on GitLab Duo Agent Platform through GitLab’s AI Gateway across all tiers and deployment models. GitLab reports that it is the first model to complete every task in its evaluation suite, compared with 93.8% for Sonnet 4.6, while resolving 8.8% more issues. The result is intended to make software-engineering agents more reliable, efficient, and suitable for production-scale workflows. ## More Reliable Agent Runs - Sonnet 5 is designed for multi-step development tasks, code generation, and automated workflows. - Completing every benchmark task reduces failures that require diagnosis, reprompting, and verification. - GitLab highlights applications including: - Multi-file refactoring - Test generation - Security investigations across repository history - Pipeline-failure analysis - Higher completion rates allow developers to review agent output instead of repeatedly restarting incomplete runs. ## Lower Cost Through Efficiency - Reliability and resource efficiency reduce the effective cost of completed agent tasks. - Models on GitLab Duo consume GitLab Credits at different rates. - Teams can control spending by using a model whose cost and performance fit routine development work. - GitLab directs users to its Credits documentation for model-specific consumption rates. ## Selecting the Right Model - Sonnet 5 is positioned as a dependable default for everyday software-development tasks. - Sonnet-class models aim to balance quality, speed, and cost. - Claude Opus 4.8 remains available for complex, long-running tasks requiring greater reasoning depth. - Teams can select models per task through model selection in their GitLab instance. ## Availability - Claude Sonnet 5 is available immediately on GitLab Duo Agent Platform through the AI Gateway. - It runs on GitLab Credits and is offered across all tiers and deployment models. - New users can start through a Duo Agent Platform trial or GitLab Free, while Premium and Ultimate subscribers can use included credits. Overall, GitLab presents Claude Sonnet 5 as a more reliable and economical choice for routine agent-assisted development, with more powerful models available when tasks require deeper reasoning.

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

How we used DSPy to turn AI evaluations into better responses in Dash chat

Dropbox uses DSPy to turn AI evaluations into improvements for its Dash chat agent. The process first calibrates LLM judges against human-labeled conversations, then uses those judges to optimize the agent’s system prompt. This feedback loop reduced incomplete answers and token usage while maintaining answer quality. ## The Complexity of Evaluating AI Agents - Agent quality depends on more than the final response: - Understanding user intent - Selecting relevant context - Choosing and using tools - Synthesizing information across documents, messages, and meetings - Handling ambiguity and follow-up turns - Producing grounded, complete answers - Evaluations therefore inspect the full interaction trajectory, not just the output. - Separate evaluations for intent understanding, tool use, context selection, grounding, adaptation, and task completion help identify the source of failures. - Reliable judges were necessary before evaluation results could safely guide agent improvements. ## Calibrating LLM Judges with Human Labels - Dropbox sampled internal chats containing final answers and agent trace logs. - Human reviewers scored five dimensions: - User-intent following - Semantic relevance - Tool calling - Instruction following - Context selection - Reviewers followed a structured process: - Determine whether the agent understood the request. - Check whether it selected appropriate context. - Inspect searches, retrievals, and other tool actions. - Verify that final claims were supported by evidence. - Score relevance, grounding, completeness, and instruction adherence. - Many metrics used a 1–5 scale. - Reviewers also added: - Reasoning notes explaining their scores - Failure codes for issues such as stale evidence, missing context, unsupported claims, incomplete coverage, and poor personalization - These richer annotations helped improve judge prompts while also supporting debugging, error analysis, roadmap planning, and prioritization. ## Using DSPy to Improve Evaluation - DSPy was used to make LLM judges align more closely with human evaluations. - Judges were required to follow a retrospective workflow: - Infer the user’s intent - Inspect the conversation and agent trace - Review supporting evidence - Assess context selection and tool use - Produce scores, failure codes, and reasoning notes - GEPA and MIPROv2, optimization algorithms within DSPy, automatically proposed and tested prompt changes against human-labeled examples. - Optimization supported several scenarios: - Rewriting judge instructions entirely - Adapting a judge to another underlying model - Targeting specific failure modes while preserving the existing evaluation behavior The overall approach creates a scalable improvement loop: human labels calibrate the judges, calibrated judges provide consistent evaluation signals, and those signals guide improvements to the chat agent itself.

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

What If AI Agents Debated Each Other? Redesigning the Development Process Through Multi-Agent Collaboration

AI coding’s main bottleneck is no longer code generation but the human coordination surrounding it: clarifying intent, validating assumptions, testing implementations, and preparing trustworthy pull requests. LY Corporation proposes an AI-native pipeline in which specialized “proposer” and “challenger” agents debate across three stages—specification, build, and delivery—while an orchestrator decides whether to revise, escalate, or proceed. The goal is for AI to substantiate its own work before human engineers review and approve it. ## Human Coordination as the Bottleneck - Traditional AI-assisted development speeds up individual tasks but leaves handoffs between requirements, implementation, verification, and review to humans. - Engineers still need to: - Write or refine specifications - Review AI-generated drafts - Transfer failed tests and feedback between steps - Inspect diffs - Prepare PR descriptions - Decide whether the result is trustworthy - The proposed solution is not to remove human judgment, but to automate repetitive coordination while preserving human ownership and final approval. ## Proposer–Challenger Collaboration - AI responsibilities are divided between two opposing groups: - **Proposers** develop specifications, implementations, and delivery materials. - **Challengers** validate them from specialized perspectives. - The separation prevents one general-purpose assistant from combining design, implementation, testing, and review into a single unchallenged response. - Specialized roles may include: - `requirements-synthesizer` - `security-analyst` - `test-coverage-reviewer` - `technical-writer` - `evidence-verifier` - An **orchestrator** mediates disagreements, redirects discussions, resolves deadlocks, and determines whether to revise, escalate, or advance. ## The Spec–Build–Deliver Pipeline ### Specification - The specification acts as a contract for all later stages. - It records: - Goals and constraints - Interpreted requirements - Explicit assumptions - Open questions - Proposed approach - Definition of done - Agents use evidence from the workspace and external sources such as Jira, Confluence, design documents, APIs, tests, dependencies, and existing conventions. - Ambiguous but low-risk and reversible issues can be documented as assumptions. - Unsafe, destructive, externally constrained, or hard-to-reverse uncertainties are escalated instead of guessed. ### Build - The approved specification is converted into a test-first verification plan before production code is changed. - The proposer identifies expected behavior, edge cases, required tests, and execution commands. - Challengers can dispute the verification design before or during implementation. - Proposers must support rejected objections with concrete evidence such as: - Execution paths - Compiler or linter output - Failing tests - Other workspace evidence - This prevents a simple green CI result from hiding missing or inadequate validation. ### Delivery - The final output is a review-ready PR package rather than merely a diff summary. - It explains: - What changed - Where reviewers should look first - Which checks passed - Remaining risks - Which challenges were already investigated - At this stage, the orchestrator acts more like a jury, judging whether sufficient evidence exists for release. ## Structured Debate Protocol - Each agent receives stage-specific context and returns structured JSON rather than a free-form essay. - Agents do not share one live context window. Shared state consists of: - Workspace files - Generated artifacts - The orchestrator’s accumulated transcript - Each round includes a proposer response, challenger response, and orchestrator decision. - The protocol distinguishes manageable uncertainty from blocking risk. - Consistent schemas make agent outputs easy to parse, compare, and feed into subsequent rounds. - For example, a challenger can identify an unclear scope boundary, explain why it matters, assign severity and confidence, and indicate whether user input is required. ## Overall Impact - Issues move through a continuous chain: debated specification, branch, tested implementation, and review-ready PR. - Humans intervene mainly to define intent, approve the final result, or resolve explicitly escalated decisions. - The central leverage comes not from generating code faster, but from requiring AI to explore, challenge, verify, and package its work before asking engineers to pay attention. The practical recommendation is to redesign AI development around explicit artifacts, specialized adversarial roles, evidence-based decisions, and automated handoffs. Human engineers should remain the final decision-makers, while AI handles the intermediate coordination and proof-building work.

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

Designing a Semantic Context OS: Beyond Token Stuffing in Agent Systems

The article argues that larger LLM context windows do not automatically produce better software-engineering agents. In long-running workflows, indiscriminately filling the context window can cause attention dilution, context rot, reasoning failures, and potential data exposure. It proposes a “Semantic Context OS,” a local runtime layer that actively governs context as a finite, structured system resource rather than treating it as an unmanaged text stream. ## The Context Window Is Not RAM - The article uses the “Karpathy metaphor”: - The LLM acts like a CPU: a largely stateless inference engine driven by pretrained parameters. - The context window acts like RAM: volatile working memory containing current state, instructions, telemetry, and runtime data. - Unlike physical RAM, LLM context is probabilistic rather than deterministic: - Traditional RAM provides precise address-based retrieval with predictable performance. - LLM retrieval depends on attention weights across Q, K, and V matrices. - Increasing capacity from 32K tokens to 1M or 2M tokens therefore does not guarantee proportionally better retrieval. Larger sequences also increase computational cost and structural noise. ## Attention Dilution and Long-Context Failure - Large codebases and logs contain substantial irrelevant material, including: - Boilerplate definitions - Unused imports - Duplicate syntax - Repeated utilities and naming patterns - As sequence length grows, the attention calculation `QKᵀ` accumulates entropy and background noise. - Softmax then spreads attention energy across more tokens, weakening the sharp attention peaks needed to retrieve important facts. - This contributes to the “lost in the middle” effect: - Information near the beginning and end of a prompt is often retrieved more reliably. - Retrieval accuracy can fall sharply across the middle portion of the context. - The article considers relying on massive, unmanaged contexts an architectural anti-pattern for tasks such as large-scale code review, dependency tracing, and automated refactoring. ## Context Rot in Long-Running Agents The article defines “context rot” as the degradation of an agent’s working context during extended autonomous tasks. - **Context poisoning** - Raw logs, obsolete errors, and previous execution data accumulate over multiple turns. - The model may treat temporary historical failures as current architectural constraints. - **Context distraction** - Monorepos often contain similar names, overloaded methods, and duplicated helper code. - Broad retrieval can overwhelm the model with structurally similar but logically irrelevant code. - **Context clash** - Old instructions may remain after the plan has evolved. - Contradictory directives can cause indecision, infinite reasoning loops, timeouts, or hallucinations. - The article claims that, without active management, failure rates increase nonlinearly with context depth and may reach roughly 40% in deeply nested codebases. ## Semantic Context OS as an AI Kernel The proposed Semantic Context OS sits between agent application logic and external foundation-model APIs, operating as a localhost loopback proxy at `localhost:8080`. Its responsibilities include: - Treating context as a finite hardware-like resource. - Tracking token lifecycles and state access. - Filtering and isolating data before it reaches the model. - Separating physical token limits from semantic governance. - Protecting downstream inference engines from structural noise and helping prevent intellectual-property leakage. The architecture includes: - A POSIX-like virtual file system for managing state topology. - A proprietary “PathAlign” stage for AST-based code-tree pruning. - An asynchronous “sawtooth” memory model for runtime token optimization. ## MVC: Minimum Viable Context The core MVC pipeline—described as “minimum viable context”—aims to provide only the smallest dense set of information required for the agent’s current reasoning step. Its processing stages include: - **Collection and token mapping** - Gather source files, dependency graphs, and runtime logs. - Map them using the target model’s tokenizer, such as `cl100k_base` or `o200k_base`. - **Structural pruning** - Use static analysis and structural rules to remove compiler comments, unused imports, boilerplate, and unrelated utilities. - The broader design replaces passive string concatenation with active context selection, lifecycle management, and bounded transmission policies. The article concludes that reliable enterprise agents require active context orchestration rather than larger prompts alone. A dedicated governance layer should prune, isolate, and refresh context throughout execution so that models receive minimal, relevant, and internally consistent information.

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

Code on the Figma Canvas | Figma Blog

Figma is introducing code layers, making interactive code a collaborative object directly on the Figma canvas. Teams can generate, import, compare, edit, and convert code and designs in both directions, bringing designers and developers into one shared workflow. The feature aims to make experimentation and design-to-code iteration more visual, collaborative, and accessible. ## Creating and Sharing Code on the Canvas - Users can add a code layer from Figma Design, convert an existing frame into code, or ask the Figma agent to generate an implementation. - Projects can begin from templates, natural-language prompts, imported GitHub repositories, or uploaded local folders. - Code generated in Figma Make can be brought into Figma Design as a code layer. - Interactive code becomes part of the shared file, allowing teammates to inspect, comment on, and refine it together. ## Exploring Multiple Alternatives - Code layers work like duplicated design frames, allowing teams to explore several working alternatives side by side. - Designers can move, resize, and adjust elements while seeing the corresponding code update immediately. - Prompts can generate new versions while preserving the original. - Teammates can collaborate on the same code layer through comments and additional prompts. ## Moving Between Code and Design - The **Extract designs** feature converts a code layer’s current state into editable Figma layers. - Teams can extract a single screen, a particular state, or an entire user flow. - Design edits can then be applied back to the code layer, enabling fluid movement between visual design and implementation. ## Editing and Shipping Code - Users can open the code editor, annotate desired changes, ask the agent to implement them, or edit the code manually. - Once approved, the updated implementation can be converted back into a code layer and pushed to the project repository. - The resulting changes remain visible to the wider team on the Figma canvas. ## Availability - Code layers are rolling out in closed beta over the following weeks. - Interested users can request early access through Figma’s Config beta sign-up. Figma’s code layers are intended to make the canvas a shared space for designing, testing, and refining real interfaces. Teams interested in combining visual collaboration with AI-assisted development can request beta access and evaluate the workflow against their existing design and repository processes.

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

Figma’s Design Agent, Now With Custom Tools and Greater Context | Figma Blog

Figma’s design agent is expanding beyond prompt-based assistance into a more context-aware collaborator that understands a team’s workflows and design conventions. In open beta, it can create reusable generative plugins, shader effects, and shader fills directly on the canvas, giving designers more control without requiring traditional development setup. The result is a more personalized and expressive design process that combines AI assistance with native Figma workflows. ## Context as the Foundation for Collaboration - Figma argues that context separates a merely productive agent from one that understands how a team works. - With knowledge of a team’s methods, the agent can collaborate rather than simply generate outputs. - Greater context also enables tools and visual effects tailored to specific design practices. ## Build Custom Generative Plugins - Designers can prompt the agent to create reusable plugins without setting up a traditional development environment. - Plugins can support tasks such as: - Importing HTML onto the canvas - Generating dashboard layouts - Organizing image assets - Visualizing data - Generative plugins use PropsKit, helping them look and behave like native Figma tools. - Because they operate directly on the canvas, designers can iterate interactively. - Classic plugins remain necessary for workflows involving external services, AI systems, or third-party APIs. - Plugins created by the user, teammates, or the Figma Community are free and available on all plans; asking the agent to create them will consume AI credits once the feature is generally available. ## Create Shader Effects and Fills - The agent can generate WebGPU-powered shaders: small programs that control how pixels are rendered. - Shader effects function similarly to native Figma effects and can be: - Customized through parameters - Stacked together - Combined with native effects - Possible effects include particle stretching, lens distortion, color outlines, dither, liquid metal, and fractal noise. - Shader fills generate dynamic visuals beyond solid colors and gradients, including: - Watercolor - Moiré patterns - Pattern grids - Halftone effects - Particle webs - Magnetic fields - Designers can use shaders to create reusable visual workflows for applications such as collage, marbling, light leaks, embossing, and prism effects. ## Designer-Controlled, Agent-Assisted Workflows - Product designer Edward Chechique used the agent to create generative tools that previously required developer assistance or switching between separate AI tools. - Creative technologist Anna Zhang used the agent to build custom image-remixing shaders while focusing on functionality and refining the interface collaboratively. - Figma presents the process as an iterative dialogue: the agent proposes solutions, while the designer guides the parameters and creative direction. - The tools are intended to help designers turn personal techniques into reusable workflows that can be shared with teams. Figma’s update positions the design agent as both a creative assistant and a tool-building partner. Designers should use it to prototype custom plugins and visual systems directly in Figma, while relying on classic plugins when external integrations are required.

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

Four travel and hospitality trends from HITEC 2026

Hospitality’s AI opportunity is growing, but most operators lack the data, infrastructure, and operational systems needed to turn investment into measurable returns. AI is reshaping how travelers discover and book hotels, while fragmented data and outdated payment systems create lost revenue and guest frustration. The strongest strategy is to connect accurate data, intelligent workflows, and seamless payments so technology improves the experience without becoming visible to guests. ## AI Is Changing the Direct-Booking Battle - Hotels historically relied on SEO to compete with OTAs such as Expedia and Booking.com. - AI-generated search answers are reducing traditional website traffic: - 65% of Google searches with AI Overviews end without a click. - The figure rises to 78% on mobile. - Traditional search traffic is declining by about 25%. - AI systems prioritize accurate, structured, machine-readable information rather than keyword density and backlinks. - More than 90% of accommodation websites are reportedly undetected by AI models. - Hotels should audit whether AI tools can correctly describe: - Room categories - Amenities - Policies and cancellation terms - Local context - Real-time availability - Winning direct bookings will require both AI discoverability and a modern checkout experience supporting local currencies, payment methods, and fraud protection. ## Hospitality AI Is Held Back by Fragmented Data - Only about 25% of hospitality businesses are actively scaling AI, and fewer than 10% are considered “AI future-built.” - Property management, CRM, loyalty, food and beverage, and payment systems often operate in silos. - Incomplete data weakens: - Personalization - Guest profiles - Financial reconciliation - Operational decision-making - The main challenge is not building AI features but operationalizing them reliably in real workflows. - Successful examples connect live data to timely actions: - Delta’s AI concierge uses customer and operational data to provide context-aware support. - Wynn’s revenue managers receive predictive alerts and recommended actions. - For most operators, better data connectivity matters more than using a more advanced AI model. ## Payment Friction Directly Affects Revenue - Payments are increasingly viewed as a competitive capability rather than a back-office commodity. - Survey findings cited in the article include: - 90% of executives consider payments important to growth. - 37% say limited payment options most harm the guest experience. - 58% report that fraud tools block legitimate transactions. - 74% say fragmented systems create excessive reconciliation work. - Guests may abandon a hotel when their preferred payment method is unavailable, shifting the booking to an OTA that supports it. - Modern payment infrastructure allows smaller operators to offer international payment methods and currencies without building large in-house teams. ## Invisible Technology Creates the Best Guest Experience - Guests have little tolerance for technology failures and may simply avoid returning rather than complain. - Effective hospitality technology should anticipate needs without drawing attention to itself. - The desired experience includes details such as: - A room set to the guest’s preferred temperature - Familiar television channels - Preferred pillow firmness - Hospitality is moving from remembering information guests explicitly provided to predicting preferences based on connected guest data. Operators should prioritize clean, connected data, AI systems tied to real operational actions, and flexible payment infrastructure. The goal is not to add AI for its own sake, but to make booking and stays more seamless while quietly improving revenue, efficiency, and guest loyalty.

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

AWS Weekly Roundup: NY Summit recap, Local Zone in Hanoi, Grok 4.3 in Bedrock, price reductions, and more (June 22, 2026) | Amazon Web Services

AWS’s June 22, 2026 roundup centers on the New York Summit’s focus on AI agents that continuously create value across work, security, software development, and customer applications. It also highlights new regional infrastructure, developer tools, Bedrock models, data capabilities, performance improvements, and several price reductions. Overall, AWS is emphasizing agent-driven automation while lowering barriers and costs for building and operating cloud workloads. ## New York Summit: Agents Across the AWS Stack - **Agents for working:** Amazon Quick supports autonomous, multi-step agents and provides a prioritized activity feed combining email, Slack, calendars, and tasks. - **Agents for securing:** AWS Continuum is an AI-native security service designed to reason about, validate, and remediate vulnerabilities across the development lifecycle. - AWS Security Agent adds threat modeling, pull-request scanning and remediation, and IDE integrations through Kiro, Claude Code, and MCP. - **Agents for building:** Kiro, AWS DevOps Agent, and AWS Transform support continuous coding, deployment, release assessment, and autonomous modernization. - Kiro now includes a native iOS app. - AWS DevOps Agent can evaluate code changes before production release. - **Agents customers create:** Amazon Bedrock AgentCore adds a generally available infrastructure and orchestration harness, Web Search, Managed Knowledge Base, Guardrails integrations, and AWS Context for mapping organizational data relationships. ## New Infrastructure and Developer Services - **AWS Local Zone in Hanoi:** The new `ap-southeast-1-han-1a` zone supports Amazon S3 and Amazon EBS Local Snapshots, helping customers satisfy local data residency and backup requirements. - **AWS Blocks:** This preview open-source TypeScript framework provides a local environment with Postgres, authentication, and real-time messaging without requiring an AWS account. Applications can later deploy to AWS without code changes, with optional CDK integration. - **AWS Management Console Private Access:** Enterprises can access the AWS Console from isolated VPCs without internet connectivity, supporting air-gapped security models. - **AWS Marketplace Storefront:** Partners can publish branded catalogs of AWS Marketplace solutions on their own websites or applications. ## AI, Data, and Agent Capabilities - **Grok 4.3 in Amazon Bedrock:** xAI’s model is available for reasoning, agentic, and enterprise workflows, with tool calling, structured output, and response streaming. - **Amazon S3 annotations:** Objects can now carry up to 1 GB of mutable, queryable context, reducing the need for separate metadata systems in AI-agent and autonomous workflows. - **Strands Agents:** The open-source toolkit adds improved Harness SDK context management, isolated execution through Strands Shell, and chaos testing and red-team capabilities in Strands Evals. - **NVIDIA-powered EC2 G7:** G7 instances use NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs and sixth-generation Intel Xeon processors, delivering up to 4.6 times the AI inference performance and 2.1 times the graphics performance of G6 instances. ## Performance and Security Improvements - **Faster Amazon ECS auto scaling:** Support for 20-second metrics reduces scale-out trigger time from 363 to 86 seconds and total scaling and task provisioning time from 386 to 109 seconds in AWS benchmarks. - **Palo Alto Networks DNS Security:** Route 53 Resolver DNS Firewall can apply PANW Advanced DNS Security protections directly, without separate firewalls or VPC changes. ## Price Reductions - **Amazon S3 Vectors:** Query charges for large vector indexes fall by up to 80%, with no application changes required. - **Amazon GameLift Servers:** Generation 6 and newer instances now include free inbound and outbound network bandwidth for both On-Demand and Spot usage. - **AWS Marketplace professional services:** Listing fees drop from 2.5% to 0.5%, reducing transaction costs for consulting, managed services, and software partners. AWS’s latest direction is to combine increasingly autonomous agents with faster infrastructure, broader model choice, stronger security, and lower operating costs. Developers and organizations should evaluate Bedrock AgentCore, AWS Blocks, S3 annotations, and the new regional and private-access options where they can simplify agent development or satisfy data and security requirements.

Read original(opens in new tab)