AI Agents

171 posts

cloudflare3 min readCurated summary

How Cloudflare detects MCP traffic and helps secure it

AI agents change the risk model for resource permissions because they make nondeterministic decisions and can repeat actions at machine speed. A mistaken judgment that a human might quickly catch can become thousands of harmful operations before anyone notices. Cloudflare’s new Cloudflare One capabilities aim to detect MCP traffic, identify its users and servers, and enforce approved routes through MCP Server Portals. ## Why AI Agents Require New Controls - Traditional permissions assumed users would apply judgment and act at a limited human pace. - AI agents can invoke tools repeatedly and indefinitely. - A single incorrect decision can rapidly propagate across databases, SaaS systems, or infrastructure. - MCP makes it easy to connect clients such as Claude Code, Codex, Cursor, OpenCode, and VS Code to approved or unapproved tools. - Direct MCP traffic can resemble ordinary HTTPS because MCP does not require a standard hostname or `/mcp` path. ## Anatomy of an MCP Tool Call An MCP request appears differently at three points: - **Client:** The agent decides to invoke a tool and supplies arguments. - **Network:** The request is transmitted as an HTTP transaction containing JSON-RPC. - **Server:** The server authenticates, validates, and dispatches the request to a tool handler. Useful protocol signals include: - Destination hostname and path - Authorization credentials - `MCP-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - JSON-RPC request `id` - Tool arguments in `params` The tool name indicates the intended operation, while the arguments may contain sensitive data such as source code, customer information, search queries, or infrastructure-changing instructions. Responses can also contain sensitive results, making both request prevention and response inspection valuable. ## Controls Inside the MCP Client Client hooks can intervene after the model selects a tool but before the request is serialized. - Enforce server allowlists - Require confirmation for sensitive operations - Remove sensitive data from arguments - Support local `stdio` MCP servers that never generate network traffic The main limitation is operational: organizations must implement controls across every client employees use. Client telemetry also cannot provide a complete inventory unless the organization manages all relevant clients and devices. ## Controls at the Network Boundary A secure web gateway with TLS decryption can inspect remote MCP traffic independently of the client. - Associate requests with users and devices - Inspect destinations and MCP protocol headers - Detect direct connections outside approved MCP Portals - Block unauthorized traffic before it reaches the server - Use data loss prevention scanning to inspect JSON-RPC methods and arguments Network controls provide the broadest visibility into remote MCP usage, but they cannot see local `stdio` calls or traffic that bypasses managed network paths. ## Controls at the MCP Server The server has the deepest execution context because it knows the authenticated caller, parsed message, resolved tool, and validated arguments. Server-side middleware can: - Authorize users for specific tools - Apply rate limits - Inspect arguments - Log outcomes - Block requests before tool execution Cloudflare’s WriteGuard applies this approach to internal MCP servers by assigning tools risk tiers and enabled or disabled states. It can allow reads, attach attribution and audit events to approved writes, or block critical actions before their handlers run. Because enforcement occurs on the server, users cannot bypass it by changing clients or disabling local hooks. ## Layered MCP Security Each control point has a different strength: - **Client controls:** Earliest intervention and support for local MCP, but limited coverage. - **Network controls:** Broadest visibility into remote traffic and unmanaged MCP connections. - **Server controls:** Richest context and final prevention point before execution. A layered strategy can protect sensitive data before it leaves a device, identify shadow MCP usage, require trusted Portal-based access, and prevent unauthorized tools from executing.

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

Try These 10 Skills—And Show Off Your Own | Figma Blog

Skills are plain-text Markdown instructions that help Figma’s agent apply a designer’s preferences, workflows, and judgment. The post argues that skills are useful not only for engineers but also for codifying creative approaches, such as easing curves, typography, image audits, and motion principles. Figma now lets users create, preview, edit, and iterate on skills directly in the product, with some also compatible with Figma’s MCP server. ## What Figma skills enable - Designers can create skills from: - A reference design frame - Specific instructions or guidelines - Repeated personal workflows - The agent can draft a skill, which users can preview and test in chat. - Skills can be refined by: - Editing instructions and formatting - Asking the agent for recommendations - Opening the Markdown editor for manual changes - Skills can capture individual design judgment and help teams reproduce a consistent point of view. - Some skills work with Figma’s MCP server and third-party agents. ## Examples of personal design skills - `/image-audit` checks whether images in a file can be exported and places a report on the canvas. - `/shader-starter` helps users write more effective shader prompts. - `/make-a-type-scale` creates a type scale from selected text and generates corresponding font variables. - `/ease-like-miggi` applies the author’s preferred easing curves to motion keyframes, allowing teammates to use the same motion style. ## `/xray-scan`: Create radiographic image effects Created by Adele Ix, this skill transforms a photo or description into a realistic X-ray image. - Produces two visual treatments: - Glowing white lines on black - Darker tones on white - Supports layered monochrome collages with glowing edges. - Is especially suited to combining multiple scans into a unified composition. ## `/find-animation-opportunities`: Identify missing motion Created by Emil Kowalski of Linear, this skill reviews a design and suggests where animation could improve the experience. - Identifies elements that should animate and areas that may be over-animated. - Recommends: - What should move - Where the motion should occur - Exact animation values - Suggestions can be implemented manually in Figma Motion or applied by the agent. - Works best when focused on one frame with contextual information, such as the target persona. - It can also be asked which elements should remain static. ## `/camera-pan-and-zoom`: Animate static compositions Created by Mallory Dean, this skill adds camera-like movement to a static design. - Builds a nested camera rig around selected content. - Supports pan, zoom, and roll animations. - Can create directed sequences, such as touring a grid of cards before zooming out to reveal the full composition. - The skill is intended to make static compositions feel more cinematic and dynamic. ## Practical takeaway Designers can use skills to turn personal techniques and repeatable creative decisions into reusable tools. Start with a focused workflow, test the generated skill in Figma, and refine its Markdown instructions until it reliably produces the desired result.

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

Write your first prompt with the GitHub Copilot app

Starting with GitHub Copilot does not require a perfect prompt or specialized syntax. The article recommends connecting Copilot to a repository or local folder, describing a task in plain English, and refining the request interactively. Users can gradually adjust the AI model, input method, and session settings as their needs become more complex. ## Start with Project Context - Connect an agent session to: - An existing GitHub repository - A local folder on your computer - Selecting a project gives Copilot access to the code and files needed for the task. - Once the project is connected, you can submit a prompt. ## Describe Tasks in Plain English - Prompts only need to explain the desired outcome. - Example: `Add a most-funded sort option to the games list.` - Copilot can inspect the codebase and identify relevant files. - If the result is incomplete or incorrect, provide more details and ask for revisions. - Prompting is iterative, so the initial request does not need to include every requirement. ## Select an Appropriate AI Model - The app supports multiple AI models with different strengths. - More capable reasoning models may help with complex tasks, while simpler models can be faster for straightforward changes. - Beginners can use the default model without understanding every model difference. - Models can be switched later if the task becomes more demanding or the initial result is unsatisfactory. ## Use Voice Input - Built-in voice input lets users describe tasks verbally. - Speech is converted into editable text before submission. - This can be useful for explaining lengthy or complicated ideas more naturally. ## Customize Agents and Sessions - Session settings allow users to select different agents for different types of work. - Remote control enables access to a session through the web. - Users can start work locally, leave their computer, and resume the same session from another device. - These options are available when needed but are not required for a first task. ## Start Small and Iterate - Begin with a modest change in a familiar project. - Review Copilot’s work and refine the prompt as necessary. - Experiment with different models or session configurations only when the task requires them. The practical recommendation is to choose a project, describe one small task in ordinary language, and begin. Experience with iterative prompting will make model selection and other Copilot settings easier to use over time.

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

From coder to orchestrator: How agents shift the role of a developer

AI agents can generate impressive one-prompt demos, but reliable software delivery requires more than isolated outputs. Developers increasingly need to design workflows that define how code is proposed, tested, reviewed, and shipped. The article argues that this shifts developers from primarily writing code to orchestrating agents within controlled, repeatable systems. ## From One-Off Prompts to Reliable Workflows - A single prompt can quickly produce a demo, such as a simple game. - Production development requires repeatable delivery with: - Appropriate context - Validation and testing - Security controls - Review processes - Clear permissions and handoffs - GitHub Copilot is presented as a control plane for connecting these parts. ## An Agentic Development Flow - Familiar repository events can trigger agent work, including: - Adding a label to an issue - Running a scheduled workflow - Starting a GitHub Actions process - The agent’s changes are captured in a pull request. - Deterministic checks then validate the work through: - Linting - Tests - Security scans - Build verification - CODEOWNERS, required reviews, and branch protection rules control what can be merged. - Agents handle ambiguous, context-heavy tasks, while predictable automation provides the safety boundary. - Developers decide: - What agents can access - How tasks are scoped - Where workflows hand off - When human judgment is required ## GitHub’s Implementation Options - Copilot cloud agent workflows support event-driven automations. - Copilot CLI can run AI-powered steps inside GitHub Actions. - Model Context Protocol (MCP) can extend agents with additional tools and external context. - These options represent different stages of building an agent-enabled development workflow. ## Starting Small - Teams should begin with one bounded, low-risk workflow. - Suitable examples include: - Issue triage - Synchronizing documentation and tests - Routine maintenance updates - The recommended approach is to integrate Copilot into existing development infrastructure rather than redesigning everything at once. Developers should treat AI agents as components within an engineered delivery system, not as replacements for that system. Start with a limited workflow, surround agent output with automated checks and review controls, and gradually expand as the process proves reliable.

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

Everything we launched during Agents Week

Cloudflare’s Agents Week presented agents as a new class of software requiring more than advanced models: they need runtimes, identity, orchestration, memory, observability, and security. Across five days, Cloudflare introduced infrastructure and tools for building, deploying, governing, and connecting agents to the web. The broader conclusion is that an “Agentic Internet” must support cooperation between humans and autonomous software while preserving control, trust, and openness. ## Agent Runtime and Infrastructure - Cloudflare introduced `@cloudflare/computer`, a runtime that lets agents select suitable computing environments rather than relying solely on containers. - Workers RPC now supports communication between Python and JavaScript Workers. - Cloudflare detailed efforts to run models such as Kimi and GLM more efficiently while maintaining quality, reliability, and safety. - The Billable Usage API provides programmatic access to Cloudflare product costs and usage. - Workers and Containers gained inbound TCP and gRPC support, enabling real-time applications such as voice AI backends. ## From Prototypes to Production with the ADLC - Cloudflare proposed the Agent Development Lifecycle (ADLC) as an evolution of the traditional Software Development Lifecycle for agent-based software. - Cloudflare Agents provide live run monitoring, tracing, replay, and human approval workflows. - Local tracing helps agents and developers debug Workers before deployment. - Cloudflare Wallets give agents programmable, secure capabilities for participating in transactions. - Programmable CI/CD pipelines can run across millions of repositories and use agents to diagnose failures and prepare fixes for review. - Cloudflare described internal AI-powered engineering workflows, including automated standards enforcement and an Astro software factory that reduced GitHub issue-management toil. ## Identity, Security, and Governance - The Agent Access Model defines how agents can access services and resources on behalf of users. - Cloudflare OS embeds AI into internal work while retaining security and human oversight, and its platform was open-sourced for building applications and automations. - Identity-aware analytics connect AI activity to users and systems, helping detect anomalous behavior and unexpected spending. - WriteGuard adds fine-grained controls to MCP servers to restrict dangerous or unwanted tool calls. ## Building an Agentic Internet - Cloudflare outlined an Internet that is readable, discoverable, callable, and payable, allowing publishers to control access while enabling agents to interact and transact. - WebMCP gives websites and web applications a simple interface that agents can discover and use. - Answer Engine Optimization (AEO) adapts SEO practices for content surfaced by AI agents. - Kitesurf is an agent-focused browser running in V8 isolates, prioritizing efficiency over pixel-perfect rendering. - MCPv2 simplifies the deployment and scaling of agentic applications. - Cloudflare AI Search turns websites and files into searchable, agent-ready data sources. ## Observing the Agent Ecosystem - Cloudflare argued that bot behavior should be evaluated through continuous trust rather than assuming bots are inherently harmful. - Workers AI and AI Gateway are being unified into a single AI control plane with one binding, wallet, and dashboard for model access. - New Cloudflare Ambassadors and Community Engineers programs support community leaders and open-source maintainers, alongside an additional $1 million in open-source funding. - Radar Researcher lets users explore Internet data through natural-language questions and interactive charts. Cloudflare’s vision is an Agent Cloud combining execution infrastructure, an increasingly automated development lifecycle, secure identity and access, agent-ready web protocols, and strong human communities. Building agents successfully will require treating them as participants in a broader computing ecosystem—not merely as model-powered features.

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

AWS Weekly Roundup: AWS Heroes Summit, Web Search on Amazon Bedrock, Dogwood, Kiro Crew, and more (August 10, 2026) | Amazon Web Services

The August 10, 2026 AWS Weekly Roundup highlights the AWS Heroes Summit and several launches focused on AI agents, modernization, data retrieval, and developer productivity. Major updates include web search for Amazon Bedrock, vector search in DynamoDB, dedicated AgentCore runtime instances, and faster Lambda networking. AWS also introduced Dogwood for temporal agent governance, portable Agent Plugins, and Kiro Crew for persistent multi-agent development. ## AWS Heroes Summit - AWS Heroes from around the world gathered for technical collaboration, deep dives, and feedback sessions with AWS teams. - The invite-only event featured: - A fireside chat with AWS CEO Matt Garman. - An AMA with James Hamilton. - Breakout sessions led by AWS product teams. - The summit emphasized knowledge sharing, community support, and collaboration between AWS experts and internal teams. ## New Amazon Bedrock and AI Capabilities - **Web Search on Amazon Bedrock** - OpenAI models, including GPT-5.4, GPT-5.5, and GPT-5.6 variants, can browse and retrieve current information from the internet. - Applications can use real-time web content while keeping data within a secured AWS environment with zero data egress. - **Runtime Instances for Bedrock AgentCore** - AI agents can run on dedicated runtime instances. - This provides more predictable performance, execution control, and costs. - **Vector Search for DynamoDB** - Applications can store and query vector embeddings alongside existing DynamoDB data. - This supports semantic retrieval and grounding for AI agents without deploying a separate vector database. ## Modernization and Lambda Networking - **AWS Transform continuous modernization** - Now generally available for analyzing and remediating technical debt across repositories. - Supports ongoing modernization of mainframe and legacy workloads rather than one-time migration projects. - Integrates with the AWS Transform Kiro Power and agent plugins. - **Higher Lambda bandwidth** - Lambda functions configured with at least 2 GB of memory and running outside a VPC can receive proportional network bandwidth increases. - Bandwidth ranges from 625 Mbps at 2 GB to 3,000 Mbps at 10 GB. - The change benefits data-intensive workloads and communication with other AWS services. ## Agent Governance and Portability - **Dogwood** - AWS open-sourced Dogwood, a governance language designed for AI agents. - It extends Cedar policies with temporal conditions. - AgentCore temporal policies can make decisions based on an agent’s prior actions within a session, not only the current request. - **Agent Plugins** - AWS supports an open, vendor-neutral specification for packaging agent extensions. - Developers can package an extension once and use it across compatible tools such as Kiro, VS Code, and Cursor. ## Kiro Crew - Kiro Crew provides a persistent workspace for collaborative, multi-agent development. - It is designed for work spanning multiple repositories, tools, and days rather than a single chat session. - Developers can run several efforts in parallel or delegate tasks to subagents that report results later. AWS’s latest updates point toward more capable, governed, and portable AI-agent workflows, while also improving modernization tools and infrastructure performance. Developers can explore the related documentation, AWS events, and the AWS Builder Center for further resources.

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

Unveiling good and bad behaviors on the Agentic Internet

The Internet contains a mix of human, automated, and hybrid traffic, so classifying visitors simply as “good humans” or “bad bots” no longer works. Cloudflare argues that website owners should evaluate continuous behavior and build trust over time, rather than rely only on isolated risk checks. Its strategy combines transparent bot classification through BotBase with behavioral detection through Precursor. ## Risk and Trust Are Different - **Risk** measures how likely a request or action is to be harmful, often based on a momentary event. - **Trust** develops over time through reputation and observed behavior. - A suspicious action should not automatically lead to rejection if the actor has an established, trustworthy identity. - Cloudflare’s goal is to create incentives for safer behavior, from blocking malicious activity to enabling beneficial automated participation. ## Verified Bots and Transparency - Cloudflare defines verified bots and agents through two requirements: - They honestly declare who they are. - They do not abuse the trust they receive. - Transparency helps site owners decide which behaviors and data uses to permit. - BotBase is designed as a directory of all known bots and agents, not just approved ones. - Actors that violate expectations can lose their verified status and become harder to trust across Cloudflare’s network. ## Continuous Detection with Precursor - Precursor is a client-side system that continuously analyzes behavior throughout a session. - Its JavaScript is injected at the CDN, so customers do not need to manually place or rerun detection code. - Unlike CAPTCHAs and other one-time challenges, Precursor evaluates behavior in context over multiple pages. - Continuous analysis makes it more expensive for bot developers to imitate human behavior across an entire session. ## What Cloudflare Has Observed - In a 24-hour snapshot, Precursor processed **206 million evaluation events across 73,438 zones**. - Suspicious behavior frequently begins in the middle of a session, meaning point-in-time checks can miss it. - A single session may shift between human and automated behavior, such as when a user hands part of a shopping journey to an agent. - Site owners therefore need classifications based on use case, purpose, and data usage rather than a simple human-versus-bot decision. ## Understanding Human Cursor Behavior - **Precursor Trace** is an interactive demonstration of part of Precursor’s detection process. - It examines cursor acceleration, corrections, rhythm, and movement texture. - The demo illustrates how behavioral signals can distinguish natural interaction from automated movement. ## Adaptive Intelligence - Cloudflare indicates that its bot detection engines will soon provide more adaptive outcomes for requests identified as automated. - The excerpt ends before detailing how this upcoming capability will work. Website owners should treat automation as a spectrum: verify transparent actors, monitor behavior continuously, and make decisions based on trust, intent, and use case rather than isolated signals.

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

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers

Cloudflare argues that AI agents need a browser optimized for machine tasks rather than human browsing. Chromium provides far more functionality than agents require while consuming too much memory and compute, limiting accessibility and scalability. The company therefore built Kitesurf, a lightweight browser running entirely on Workers and designed for agentic workloads. ## Why Cloudflare Built a New Browser - Cloudflare had repeatedly considered building a browser but previously found the technical investment difficult to justify. - Recent advances in its Developer Platform changed the equation: - Mature WebAssembly support in Workers - Dynamic workers - SQLite-based Durable Objects - Worker-to-worker RPC and service bindings - Improved Node.js compatibility and higher platform limits - Growing demand for AI browser automation exposed Chromium’s limitations: - High CPU and memory consumption - Expensive dedicated browser instances - Poor scalability for large numbers of agents ## Designing for Agents Instead of Humans - Agents prioritize: - Low token counts - Large context windows - Scalability and performance - Low operating costs - Structured, machine-readable content - They do not need many human-oriented features, such as: - Tabs, themes, extensions, and device synchronization - Pixel-perfect rendering - Smooth 60-frame-per-second scrolling - AI browser security requires a different threat model, with prompt injection and tool safety treated as central concerns. - Kitesurf became the result: a browser available in beta through Cloudflare’s Browser Run product. ## From Prototype to Product - The project began with inspiration from Obscura, a lightweight Rust headless engine for AI automation. - Cloudflare used an AI agent to attempt a port to Workers. - The first prototype was weak, but a detailed plan and explicit success criteria allowed the agent to iterate effectively. - The promising proof of concept led the team to develop Kitesurf further. ## Testing as a Foundation - Cloudflare relied heavily on automated testing to accelerate development without sacrificing quality. - Web Platform Tests (WPT) provided standards-based criteria for implementing browser features. - Engineers curated feature assignments and sequencing so AI agents could work toward measurable goals. - Because WPT does not fully capture real-world website behavior, Cloudflare added: - Multistep Puppeteer integration tests - Comparisons against Chromium - Visual regression checks at every interaction step - This combination tested both standards conformance and practical rendering behavior. ## Rust and WebAssembly - Kitesurf uses Rust wherever possible and compiles directly to WebAssembly with `wasm-bindgen`. - This avoids the bulk and performance costs associated with Emscripten’s emulation layers and mocked dependencies. - The approach allows browser components to run closer to native performance inside Workers. ## Resilience Through Exception Handling - Since browsers must process unreliable and potentially hostile web content, failures must not terminate entire sessions. - Kitesurf follows a strict rule: - Errors degrade to a blank frame or missing element - Faults are caught at component boundaries - Safe empty defaults are used - Diagnostic information is logged - This makes individual rendering failures survivable rather than allowing malformed input to crash the browser. ## Isolation and Statelessness - Every page load is treated as untrusted input. - Sessions begin fresh, and components receive only the resources they require. - Workers provide isolation boundaries, but Kitesurf also enforces isolation within the application itself to prevent data leakage between pages. - Components are kept stateless wherever possible: - Failed components can simply be recreated - Work can be scaled horizontally and run in parallel - Burst-based workloads avoid the cost of maintaining idle instances - Recovery can consist of restarting a component and replaying a request Kitesurf’s central recommendation is to build browsers around the needs of their users—in this case, AI agents. By sacrificing human-focused features and emphasizing efficiency, structured output, isolation, resilience, and scale, Cloudflare aims to make browser automation practical for a much broader range of agentic applications.

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

How we’re rethinking work at Cloudflare with Cloudflare OS

Cloudflare built Cloudflare OS to let employees use AI agents safely after a sudden increase in demand for production access and automation capabilities. The company’s approach combines AI enablement with strict controls around data access, human accountability, organizational context, and engineering quality. Its experience suggests that successful AI adoption requires meeting both technical and non-technical users where they work. ## Why Cloudflare Built Cloudflare OS - Employees rapidly began using improved AI models and agent-building tools to create internal applications. - One sales employee requested production access to roughly a dozen systems and administrative deployment permissions for an AI-built “SuperApp.” - Cloudflare needed to enable experimentation without exposing internal systems, company data, or customer data. - The resulting platform combines existing products such as Workers and Access with custom services developed for internal AI workflows. ## Principles for AI Adoption - **Start with jobs to be done:** Teams should identify customer-related pain points, bottlenecks, or missed opportunities before selecting an AI tool. - **Give everyone access to AI capabilities:** AI interfaces should not be limited to developers using terminals, code editors, and repositories. - **Keep humans accountable:** Employees remain responsible for defining quality, testing outputs, and owning the workflows and agents they deploy. - **Prioritize organizational context:** Cloudflare-specific knowledge and canonical internal guidance matter more than simply choosing the most powerful model. - **Never expand permissions through AI:** AI tools and agents must inherit users’ existing access restrictions and receive only the permissions required for their tasks. Shared agents must respect each recipient’s permissions rather than the deployer’s. ## Engineering Guardrails with the Cloudflare Engineering Codex - Cloudflare created the Engineering Codex as an authoritative, opinionated guide to engineering practices. - Unlike policies, which define what engineers cannot do, the Codex describes what they should do. - Domain owners are responsible for defining quality standards across the codebase. - AI agents use the Codex throughout the software development lifecycle: - Planning work - Reviewing merge requests - Evaluating technical designs before implementation - Reviewing incident reports - Over four months, these agents identified nearly 250,000 potential issues, blocked 16,000 merges, and caught architectural problems in almost 600 designs. - Cloudflare is now focusing on helping engineers create evaluation loops for assessing the work produced by their agents. ## Rethinking AI Tools for Non-Engineers - Cloudflare initially gave non-engineering employees developer-oriented tools with more approachable interfaces. - This approach worked poorly for knowledge workers who create one-off deliverables and interact with many systems of record. - Code-focused harnesses encouraged excessive “vibe-coded” applications, often without a clear problem to solve. - Cloudflare then began working backward from users’ actual needs and introduced the idea of a “magic AI email bot” to which employees could delegate unwanted work. The supplied excerpt ends before describing how that system worked. Cloudflare’s experience recommends pairing broad AI access with strong identity, permission, context, and accountability systems. Organizations should design tools around real jobs to be done—not simply distribute coding agents—and provide interfaces suited to both engineers and non-engineers.

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

Cloudflare OS: an open platform for agents, apps, and work

Cloudflare OS is an open-source platform that gives every employee an agent workspace grounded in their organization’s terminology, procedures, systems, and best practices. It combines conversational agents, code execution, connected apps, workflows, and governed access to internal data. Cloudflare’s experience showed that security and resource-level authorization must be built into the platform rather than left to individual users or app developers. ## Why Organizations Need More Than Coding Agents - Code provides a clear feedback loop: it either works or fails. - Other organizational work—documents, research, processes, relationships, and physical-world outcomes—is harder for agents to support. - Agents need both: - Context about how the company operates. - Access to the systems employees use. - Cloudflare OS was created to apply agent leverage across the entire organization, not only engineering. ## Lessons from the First Version - Cloudflare’s initial system gave employees private agent workspaces. - Early limitations included: - Static apps that were not connected to live internal systems. - Repeatedly rerunning agent skills for mostly deterministic tasks, consuming additional model tokens. - Collaboration risks when users shared workspaces, apps, and outputs. - MCP servers could define which tools an agent could call, but not which underlying resources the agent had seen. - The platform therefore needed security that tracked data access and possible downstream exposure. - The new version makes security, governance, customization, and organizational context core platform features. ## Cloudflare OS Platform Components Cloudflare OS combines: - **Agent workspaces:** Browser-based environments with sessions, persistent state, files, resource access, and isolated code runtimes. - **Security and governance:** Controlled access to internal services and data. - **Personal and collaborative apps:** Modifiable applications that users can build, share, and continue evolving. - Conversations can become documents, applications, or workflows that continue operating after the initial interaction. ## Agent Workspaces for Everyone - Employees can use workspaces through a browser without being developers or using a terminal. - Company-curated skills and context prevent users from repeatedly explaining terminology, processes, and best practices to an AI model. - Shared skills allow improvements discovered by one person to benefit the wider organization. ### Research and Analysis - Agents can research using approved company context and resources. - They can write code to search, filter, join, and analyze data without loading entire datasets into the model’s context window. ### Documents, Slides, and Spreadsheets - Agents can convert research into editable documents, presentations, and spreadsheets. - Outputs can remain connected to live data, update when sources change, and be exported to services such as Google Drive. ### Connected Team Applications - When static documents are insufficient, agents can create applications with interfaces, logic, and persistent state. - These apps can use connected company resources and support collaboration among multiple users. ### Deterministic Workflows - Repetitive jobs can be implemented as workflows rather than full agent sessions. - Code handles predictable steps, while models are used only where judgment is needed. - Workflows can run manually, on schedules, or in response to events. - Access to systems of record is provided through Gatekeepers, while existing MCP servers can be connected through MCP Server Portals. ## Security and Governance - Directly distributing API keys to employees or agents creates broad, long-lived access that is difficult to constrain and audit. - MCP improves credential handling by keeping keys in servers and exposing defined tools. - Tool-level control is not sufficient: agents may combine data from multiple systems, move it to less restricted locations, or expose it through apps and generated outputs. - Authorization must therefore consider not only which tools an agent can use, but also which resources it has observed and where that information can go. ### Default-Deny Access - Cloudflare Access controls entry into Cloudflare OS. - Within the platform, every agent and app begins with no permissions. - An agent must request access to a specific resource, which can be approved or denied. - Approved resources are exposed to generated code through typed bindings such as `env.PROJECT`. - These bindings represent narrowly scoped capabilities under a specific policy. - Credentials remain isolated from both the agent and the generated code. Cloudflare OS is intended as a customizable organizational platform: companies can deploy it, connect internal systems, encode their operating knowledge as skills, and give employees governed tools for building useful apps and workflows. Its default-deny, resource-aware security model is essential for safely sharing agent-generated work across an organization.

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

WriteGuard: Fine-grained controls for MCP Servers

Cloudflare built WriteGuard to safely expand AI agents’ write access to internal MCP servers. The system centralizes authorization, risk classification, agent attribution, and auditing, addressing failures that client-side prompts or individual user vigilance cannot reliably prevent. It preserves the human user’s permissions while making each agent session identifiable and its actions queryable. ## The Risk of Uncontrolled Agent Actions - A broadly instructed cleanup agent accidentally closed thousands of tickets. - Human and agent actions were recorded under the same employee identity, making the incident difficult to investigate and repair. - Network logs could not distinguish between multiple agent sessions. - More serious failures could involve: - Amending contracts - Sending mass customer replies - Deleting database tables - Triggering destructive production actions ## MCP Fundamentals - The Model Context Protocol connects AI applications to external tools and data. - An MCP server exposes tools with: - A name - A description - An input schema - A handler that performs the operation - When an agent selects a tool, the MCP client sends the call to the server, which interacts with the downstream application. ## Cloudflare’s MCP Expansion - Cloudflare uses MCP with local clients such as OpenCode and Cloudflare OS, as well as long-running agent services. - Its internal MCP portal grew from 13 servers to 27. - Servers initially provided read-only access to systems such as Jira, GitLab, internal documentation, and operational tools. - As agents became more capable, teams requested write actions across engineering, product, design, sales, and customer success. - Cloudflare decided centralized controls were necessary because client-side skills and elicitation prompts vary across agent harnesses and can be disabled. ## WriteGuard’s Policy and Attribution Layer - WriteGuard evaluates tool configuration together with request context. - It can: - Pass a call through unchanged - Add agent attribution to supported writes - Create a scrubbed audit event - Block a call before the tool handler executes - Policies are defined per tool and include: - Risk tier - Enabled or disabled status - Labeling configuration - Risk tiers include: - **Read Only:** Search issues or inspect merge requests - **Minimal Impact:** Add reactions or mark notifications read - **Contained Write:** Add comments, create merge requests, or update issue fields - **Critical:** Merge code, deploy to production, or bulk-delete records - Labeling allows agent context to be inserted into downstream applications in formats such as plain text or HTML without modifying the MCP server. ## Preserving Human Permissions While Identifying Agents - Agents operate through the employee’s Cloudflare Access and OAuth identity. - An agent cannot perform an action its user is not authorized to perform. - Cloudflare avoided standalone agent accounts because they would create additional permissions to manage and weaken accountability. - WriteGuard supplements the human identity with MCP client and session information. - Each write can therefore be tied to both the responsible person and the specific agent session. ## Centralized, Queryable Auditing - WriteGuard classifies every invocation as successful, failed, or blocked. - It asynchronously sends scrubbed events to an internal audit Worker. - Audit records include: - MCP server and tool - Risk tier - Outcome - User and client - Request duration - Secret and sensitive input values are omitted. - Asynchronous logging avoids adding latency to the agent’s response. - MCP portal logs show raw tool invocations, while WriteGuard adds semantic classifications, agent context, and backing-service outcomes. - Central auditing makes unusually fast or widespread agent activity easier to detect and investigate. ## Recommendation Organizations expanding MCP agents beyond read-only access should use centralized, server-side policy enforcement, preserve human authorization boundaries, attach per-session agent attribution, and maintain scrubbed audit logs. Relying solely on prompts, client configuration, or undifferentiated user identities makes destructive automation difficult to prevent and even harder to understand afterward.

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

The Agent Development Lifecycle has arrived on Cloudflare

AI has made software implementation dramatically faster, exposing bottlenecks in testing, deployment, maintenance, and operations. Cloudflare argues that software development must evolve from the human-centered SDLC to an Agent Development Lifecycle (ADLC), where agents manage the full process rather than merely generate code. This requires software factories with APIs, observability, scalability, permissions, reproducibility, and self-improvement built in from the start. ## AI Has Overloaded the Traditional SDLC - The SDLC typically covers planning, design, implementation, testing, deployment, maintenance, and retirement. - AI has made implementation cheaper and faster, overwhelming downstream activities: - Open-source maintainers face huge volumes of issues and pull requests. - Production teams must handle software delivery at unprecedented speed. - Many organizations still use agents only for coding while humans perform validation, review, deployment, monitoring, and bug triage. ## From Software Teams to Software Factories - A software factory accepts inputs such as: - Production errors - Customer bug reports - Feature ideas - Agents then autonomously build, improve, deploy, and manage software. - The goal is to reduce human involvement in routine coordination and reserve human time for design, customer understanding, judgment, and creativity. - Cloudflare treats agents as customers and provides APIs that let them interact with its products and services across the SDLC. ## Requirements for Agent-Driven Development Software factories must redesign human-oriented processes so agents can operate safely and independently: - **Programmatic:** Every operation needs a reliable API; manual “ClickOps” cannot support agents. - **Horizontally scalable:** Each agent should receive isolated, production-like preview environments. - **Reproducible:** Systems must reproduce complex conditions, such as device, network, or geographic variations. - **Real-time and push-based:** Events should trigger agents instead of relying on humans to inspect dashboards. - **Atomic:** Changes must be independently testable, releasable, observable, and reversible. - **Permissioned:** Agents need controlled access and mechanisms to safely escalate permissions when necessary. - **Self-improving:** Agents must learn from prior work and operational experience. ## Cloudflare’s Initial ADLC Tools Cloudflare describes several projects intended to extend agents beyond code generation: - `@cloudflare/ci`: CI/CD infrastructure designed to operate across millions of repositories, self-heal, and spawn agents for complex tasks using Cloudflare Workflows. - OpenTelemetry traces in local development: Gives agents production-like observability through Wrangler and the Cloudflare Vite plugin. - Cloudflare Agents and Agent Traces: Provides tools for observing, maintaining, and improving agents. - AI-enforced engineering standards: Applies best practices across products, systems, and specifications. - An Astro software factory: Automatically triages, reproduces, verifies, and fixes GitHub issues to reduce the project’s issue backlog. ## Autonomous Software Requires Purpose-Built Infrastructure - Traditional SDLC tools and linear GitHub Actions workflows are designed around human decision-making and do not cover the complexity of autonomous software delivery. - Agents must handle subjective requirements, cross-functional dependencies, production risks, and operational feedback—not just run tests and open pull requests. - Like autonomous vehicles, software agents need specialized sensors, feedback systems, controls, and remote intervention capabilities rather than being placed in systems designed for humans. - The relevant standard is not whether an agent succeeds most of the time, but whether it can achieve the reliability and safety required for production. The practical recommendation is to treat agents as participants in the entire software lifecycle. Organizations adopting AI at scale should build the APIs, observability, isolation, permissions, event systems, and feedback loops needed for safe software factories—not simply add agents to existing human workflows.

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

How we built a software factory to drive Astro’s GitHub issue count to zero

AI-powered software factories can address a pressing open-source problem: maintainers are overwhelmed by the flood of AI-generated issues, pull requests, and security reports. The Astro team built an automated triage pipeline that reproduces bugs, diagnoses causes, creates fixes, and ships preview releases for verification. After several months, it reduced Astro’s open issues from more than 200 to roughly 30 without mass-closing or ignoring reports. ## Building an Issue-Triage Skill - The team began by automating issue triage, one of the most time-consuming parts of open-source maintenance. - The workflow mirrors manual debugging: - **Reproduce:** Clone the reporter’s reproduction repository and confirm the problem. - **Diagnose:** Instrument the code and add logging to identify the root cause. - **Verify:** Check tests, documentation, and comments to determine whether the behavior is actually a bug. - **Fix:** Turn the reproduction into failing tests, implement a solution, and deploy it. - Each phase runs in an isolated AI subagent to reduce the tendency to force a solution. - Subagents communicate through a sequential `report.md` file containing their findings. ## Running the Pipeline in GitHub Actions - The workflow is driven by GitHub issue labels rather than a separate internal database. - New issues begin with `triage needed`; verified fixes eventually move to `fix verified`. - The pipeline reconstructs its state from labels and existing issue comments. - When a fix is ready, it: - Creates a preview release using `pkg.pr.new`. - Posts the diagnosis, logs, and installation instructions to the issue. - Lets the original reporter test the patch. - Opens a linked pull request after confirmation. ## From a Repository Workflow to Flue - The team recognized that the process was not inherently tied to GitHub. - Its core structure consists of: - An external event. - A sequence of isolated subagents. - Separate reasoning and execution permissions. - Durable workflow state. - This generalization became **Flue**, an open, platform-agnostic framework for agent workflows that can respond to GitHub events, Slack messages, cron jobs, or webhooks. ## Effects on Maintainer and Community Work - Automation did not make the Astro team less connected to users. - Instead, it freed maintainers to spend more time: - Engaging with the community in Discord. - Participating in RFCs and feature discussions. - Collaborating with contributors. - The system is designed to resolve most incoming issues, while failures are treated as signals that the codebase needs improvement. ## Using Agent Failures to Improve the Codebase Agent mistakes often reveal problems that would also challenge human developers: - **Opaque abstractions:** Component boundaries are unclear. - **Missing documentation:** Important implementation decisions are unexplained. - **Insufficient testing:** Critical behavior lacks adequate unit tests. - For example, the bot repeatedly changed an HMR-related condition and caused regressions because the logic was poorly documented and under-tested. - Adding a precise comment clarified the intended behavior, after which the bot stopped making the same incorrect change. - Fixing these weaknesses improves both future automation and human maintainability. ## Extracting the Workflow into a GitHub Action - Initially, the triage system was embedded in the Astro monorepo, making changes risky and difficult to test. - The team separated it into the standalone `triagebot-action` repository. - This enabled independent testing and safer updates to Flue and the workflow. - The action now supports Astro and has been adopted or forked by other teams building their own automated development pipelines. The practical lesson is to start with a narrow, repeatable maintenance task, isolate agent responsibilities, make all reasoning auditable, and use failures to improve documentation, architecture, and tests.

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

Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet

Cloudflare is introducing Wallets to help AI agents discover, test, and pay for APIs without relying on humans to handle registration, billing, and API keys. Account Wallets will fund agent-controlled Virtual Wallets with configurable spending limits, while stablecoin micropayments through the x402 protocol enable machine-native transactions. Cloudflare also proposes human-readable wallet identities so merchants can recognize agents and their sponsoring organizations. ## The Challenge of Agent Onboarding - APIs are typically designed for humans, requiring login pages, payment methods, and manual API-key generation. - Agents lack: - Stable identities for signing up. - Native payment mechanisms. - As a result, agents often abandon API evaluation and delegate onboarding back to humans, limiting agentic commerce. ## Cloudflare Wallets and x402 Payments - Users can claim a Cloudflare Wallet handle that provides a persistent username for interactions with merchants. - Wallets will support: - Storing stablecoins. - Purchasing APIs, content, and other services. - Receiving funds. - Cloudflare’s Monetization Gateway will let eligible customers sell APIs and content through the x402 protocol. - x402 attaches micropayments directly to HTTP requests, supporting uses such as AI inference, data access, and content consumption. ## Account Wallets and Virtual Wallets - **Account Wallets** - Belong to human Cloudflare account owners. - Can be funded and drained by the owner. - Delegate spending authority to agents through Virtual Wallets. - **Virtual Wallets** - Are designed for agents and accessed through API keys. - Let agents spend independently within owner-defined limits. - Can enforce allowances, merchant allow lists, and maximum transaction sizes. - This structure gives agents autonomy while preventing uncontrolled spending. ## Enabling Low-Risk Exploration - Agents can try dozens or hundreds of APIs with inexpensive x402 micropayments. - Spending caps make autonomous experimentation safer: a small budget can support many low-cost trials. - Organizations could assign policies such as a $100 weekly AI-inference budget to each employee or agent. - Agents exceeding their limits can request a human override. - Administrators can review unusual spending, raise limits, or provide one-time funding when appropriate. - Cloudflare plans to support traditional funding and withdrawals in selected regions, with stablecoin self-funding available to eligible users. ## Building a Two-Sided Agentic Market - Monetization Gateway gives merchants tools to sell resources directly to agents. - Wallets add the buyer-side infrastructure needed for agents to purchase APIs, MCP tools, and content. - Together, these systems aim to create a machine-native marketplace where agents can transact without constant human intervention. ## Persistent Agent Identity - Merchants often cannot tell which person or organization an agent represents. - This makes it difficult to provide trials, credits, or other benefits without enabling abuse through large numbers of agents. - Wallets linked to Cloudflare accounts through `cloudflare.pay` will let agents optionally identify themselves. - An identity such as `research.example.cloudflare.pay` could indicate both the agent and its associated organization. - Agents may remain unidentified, while merchants can choose whether to prioritize known identities. ## Human-Readable Identifiers - Cloudflare compares agent identity to VPN use: an unidentified agent is not necessarily malicious but may need to establish greater trust. - Existing systems such as Web Bot Auth can associate agents with cryptographic keypairs. - Cloudflare Wallet handles would make those otherwise opaque identifiers easier for humans to recognize. - The proposal intentionally avoids defining a complete identity or verification standard, focusing instead on a simple, memorable naming layer. Cloudflare’s Wallets are intended to give agents both the ability to transact and the freedom to explore services safely. Account-level controls, Virtual Wallet spending policies, and optional persistent identities could provide the foundation for a more autonomous but accountable agentic economy.

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

Code, Craft, and the Making of Nested Folders | Figma Blog

Figma’s nested folders feature required much more than a file-browser update: it involved rethinking content structure, permissions, sharing, administration, and core infrastructure. The team responded to changing priorities and faster AI-assisted development by replacing a sequential product process with code-led experimentation, flexible roles, and continuous collaboration. This approach helped them turn early ideas into working solutions and ship a complex, long-requested feature. ## Nested folders required foundational changes - Nested folders help growing teams organize files within shared projects. - Implementing them affected: - The file browser - Admin controls - Sharing and permissions - Figma’s underlying content model - Core infrastructure - The feature was therefore treated as a systems-level redesign rather than a simple quality-of-life improvement. ## Moving beyond the traditional product process - Initially, the team followed a conventional sequence: - Product defined requirements. - Design mapped the user experience. - Engineering started implementation after the concepts were considered complete. - Midway through the project, priorities shifted as resources were also needed for AI-native initiatives. - Tools such as Figma Make, the Figma MCP server, agent skills, codebase prototyping, and context-aware agents made it possible to begin work from prototypes, code, or even informal ideas shared in Slack. ## Leading with code - As code became faster and cheaper to produce, the team used pull requests as a way to explore product ideas. - Working prototypes and PRs helped the team test assumptions directly instead of spending too long debating theoretical solutions. - Code became a proposal and a communication tool, not merely the final implementation step. ## Flexible roles and shared ownership - Responsibilities shifted according to the problem being solved: - Engineers made design decisions. - The designer contributed code. - The product manager focused less on daily execution and more on strategic questions. - This flexibility allowed the team to respond quickly as technical and product requirements evolved. ## Replacing handoffs with conversations - Blurred roles turned team members into both students and teachers. - Instead of relying on formal handoffs between product, design, and engineering, the team collaborated continuously. - Sharing specialized knowledge and previously guarded parts of each craft helped build the trust needed to make decisions quickly. The broader lesson is that complex product work benefits from treating code, design, and product thinking as shared responsibilities. For teams building foundational features under changing conditions, early prototypes, cross-functional ownership, and ongoing conversation can be more effective than rigid sequential handoffs.

Read original(opens in new tab)