BRIEF DELIGHTS

💡 WHY THIS MATTERS FOR YOUR ROLE

Giving your agents access to your tools, data, and services is what makes them useful. As agents perform deeper work across systems, authenticating and authorizing that access becomes central to your application architecture.Today, agent access is usually granted through long-lived provider tokens stored in your environment variables, provisioned for everything your agent might need. These tokens are shared across every user, never expire, and give your agent full reach across every task, no matter how small the job.A vault makes that token harder to steal. It doesn't make it less dangerous. The problem is what happens when the token leaks: everything it can touch is now exposed.We built Vercel Connect to solve this problem. Now in Public Beta, Vercel Connect replaces the stored token with runtime credential exchange. You register a connector once. When your agent has work to do, your app proves its identity to Vercel Connect and gets back a short-lived credential, scoped to the task. Everything you used the token for still works. The agent just requests access each time instead of holding it.Register a connector once, then reuse it across projects and environmentsA connector is a reusable connection between your Vercel team and a provider like Slack or GitHub. You create it once from the dashboard or the CLI, then attach it to the projects and environments that need it, with project-level access controls.The relationship with the provider becomes a single entity you can see and manage, not something scattered across a dozen environment variable panels where a rotation means hunting down every copy.Your coding agent can run this setup too. Install the vercel-connect skill with npx skills add vercel/vercel-plugin --skill vercel-connect, and it can create and attach connectors for you.Request scoped tokens at runtimeWith a connector in place, the agent asks for a credential only when it has work to do. The @vercel/connect SDK returns a token you use immediately against the provider API, and no provider secret lives in your app.Tokens are short-lived, with a lifetime that depends on the provider. The SDK refreshes them automatically, so you never rotate a secret by hand. That leaves one question. If your app holds no secret, what proves it's allowed to ask?The app proves its identity with OIDCThe proof is an identity your app already has. Every deployment on Vercel gets an OIDC identity, and when your app or agent requests a token, the SDK presents that identity to Vercel Connect. Vercel Connect verifies it, checks that the project and environment are allowed to use the connector, and returns the provider credential. That round trip is the runtime credential exchange.The same identity is available during local development through vercel link and vercel env pull, and outside Vercel, the SDK accepts a Vercel access token. Either way, there is no provider secret in your app to leak, commit, or copy between environments.Scope each token to exactly what the task needsNot every task needs the same reach, even within a single agent. One step might read a repository while the next opens an issue. Each requests exactly the access it needs, and the request itself sets limits. A request can include:Provider scopesAn installation IDResource restrictionsProvider-specific authorization detailsGitHub is the sharpest example because it can restrict a token to specific repositories and permissions.The deployment agent can read that one repository and do nothing else. A fine-grained GitHub App install can be narrow too, but an install is a standing grant, set up once and trusted from then on. This limit exists for one request, one task. Least privilege becomes the shape of the request.Act on behalf of a specific user, with per-user token scopingA shared bot token gives every user's request the same identity and reach. Vercel Connect lets you set that identity. Switch subject from the app to a named user, and the token acts on that user's behalf, scoped to what that user authorized.When a user first grants access, startAuthorization runs the consent flow through a callback URL, a webhook, or a device code. After that, the agent requests tokens as that user.Contain access by environment, and revoke it when you need toA connector is attached to the projects and environments you choose, so you can run a separate connector for development, preview, and production instead of pointing one at all three. When each environment has its own connector with an authorization grant and scopes, a credential compromised in development cannot be replayed against production.Separate connectors limit where a credential works, but they don't pull back access already issued. That's normally the painful part. With a stored token, that means a rotation. You mint a new secret, update every place the old one lived, and redeploy whatever depended on it. With Vercel Connect, you revoke the connector's tokens, either your own or all of them.What revoking does depends on the provider. Where the provider supports revocation, Vercel Connect revokes the token at the provider. Where it does not, Vercel Connect stops issuing new tokens for that grant, and a token already issued stays valid at the provider until it expires. That is a real limit on any provider without a revocation API, and the shorter the provider keeps its tokens, the smaller that window is.Drive event-driven agents from verified Slack triggersSo far, your agent has been the one reaching out. It requests a token and calls a service when it has work to do. Triggers run the other way. A connected service sends an event to your app, and your agent responds.Vercel Connect receives the provider's webhook, verifies it, and forwards it to your project. Trigger forwarding is in beta and supports Slack, GitHub, and Linear today. A Slack connector can forward its verified webhooks to up to three of your projects, so a message in Slack can wake an agent that acts on it.The flow runs end to end without a provider secret in your app:A user posts a message in Slack.Slack sends the event to Vercel Connect.Vercel Connect verifies the event against the Slack signing secret it holds, then forwards it to your Vercel app, re-attested with its OIDC identity.Your app verifies that attestation, then requests a scoped runtime token.The agent acts and responds.The Slack signing secret does not disappear. It moves server-side to Vercel Connect, which verifies the upstream webhook and re-signs the forwarded request with an identity your app can check. Your app holds no bot token to act with and no signing secret to verify against.Vercel Connect meets your code where it already isUnderneath everything is one call. Whether your agent is built on the AI SDK, runs as a background job, or is a loop you wrote yourself, it asks for a token the same way, with getToken. Around that call are adapters for the stack you already run. Better Auth (@vercel/connect/betterauth) and Auth.js (@vercel/connect/authjs) get provider configs in the shape they expect, and @vercel/connect/ai-sdk and @vercel/connect/mcp do the same for AI SDK tools and MCP clients. The Nuxt starter gives you a working app to build on, with GitHub and Linear connected, no provider secret, and no OAuth refresh token stored in its database.Frameworks can take this further and make the connection itself declarative. In eve, the open-source agent framework by Vercel, a connection is one file, and the @vercel/connect/eve adapter supplies that connection's credential.There is no token handling in the agent's code, because connect maps the consent flow, refresh, and error cases onto eve. Any MCP server that supports OAuth can become a connector by its URL, which is how mcp.linear.app ends up with the same scoped-token model as Slack or GitHub.The same adapter wires a Slack channel. One connectSlackCredentials call covers both directions: the bot credentials for sending and the webhook verification for receiving.The two secrets a Slack integration usually keeps in your environment, SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET, are gone from your app. There is nothing left to provision, store, or rotate.Access becomes something you request, scoped to the taskAn agent becomes more useful the more it can reach, which is exactly why access is the part to get right. Every system the agent can touch is a system someone could reach through a leaked token. With runtime credential exchange, nothing is provisioned for everything. Nothing is shared by every user. Nothing lasts forever. Nothing reaches past the task in front of it.Credential management used to be architecture. It was rotation scripts, secrets copied between environments, and bot tokens broad enough that you hoped no one leaked them. Now you store none of it. You request access the moment the agent needs it, scoped to the task.Start building with Vercel ConnectRegister a connector, request your first runtime token, and connect an agent to Slack or GitHub without storing a provider secret.Coding agents just need a prompt:Frequently asked questionsWhat is Vercel Connect?Vercel Connect lets your agents and services access external systems on behalf of your users and teams. Instead of storing provider credentials in long-lived environment variables, you request user-authorized tokens at runtime with project-level access controls.What problem does Vercel Connect solve?It removes long-lived third-party secrets from your runtime while still letting agents act on external APIs. You register a connector for a provider, link it to projects and environments, and request provider tokens at runtime.When should I use Vercel Connect instead of Integrations?Use Vercel Integrations for marketplace-managed installs and provider-managed products in the Vercel Marketplace. Use Vercel Connect when you need delegated runtime credentials and user authorization for agent workflows, such as an agent that needs project-scoped access to a Slack workspace.Which connectors are available?Vercel Connect supports generic OAuth and API key connectors, as well as managed connectors for Slack, GitHub, Linear, and other platforms. It also includes support for 100+ preset connectors, such as Notion, Shopify, Resend, Sanity, and Workday.How does pricing work?Pricing is based on token requests. The Hobby plan includes 5K token requests per month at no additional cost. On Pro and Enterprise plans, token requests are billed at $3 per 10K token requests.What are the current Beta limitations?Trigger forwarding is limited to Slack, GitHub, and Linear, connector branding fields cannot be fully cleared after you set them, and token revocation, token lifetime, and scope granularity depend on provider support. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Core web app decisions tend to center the backend, due to its complexity and impact over huge swaths of the business.However, frontends have grown far more important and complex in their own right. When not prioritized, the intricate infrastructure around them can quickly spin out of control, dragging teams into untold amounts of tech debt.As decoupled architecture becomes more common, developers are turning to the Frontend Cloud to automate away the behind-the-scenes hassles of creating and growing dynamic websites.Instead of managing infrastructure as a separate step of the development process, the Frontend Cloud provisions global infrastructure for you, based on your existing application code. This approach to web development massively increases developer velocity, allowing your team to experiment safely and meet shifting market demands. Teams of all sizes can effortlessly scale global apps while maintaining the highest possible bars for performance, personalization, and security.You can think of the backend cloud as your cost center and the Frontend Cloud as your profit center. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Amazon EC2 R9g and R9gd instances powered by AWS Graviton5 are now generally available, delivering up to 25% better compute performance than R8g, ideal for databases, in-memory caches, and real-time analytics.

💡 WHY THIS MATTERS FOR YOUR ROLE

By Dhruv PratapIntroductionOrganizations that have been around for a while usually run two identity systems side by side. One belongs to the cloud provider: IAM roles, instance profiles, execution roles. The other is your own, and it is the one your internal services actually check when they decide whether to answer a request.On infrastructure you build yourself, you can bootstrap your own identity however you like. On managed compute you cannot. The provider hands your process a cloud identity and nothing else.This post describes how we close that gap for Apache Spark workloads running on Amazon EMR. A workload that starts with only an AWS identity has to end up holding a first-class internal identity. Doing the exchange is straightforward. Making it trustworthy is the part that took the design work. Very little of what follows is specific to Spark or to EMR.Two identity systemsInternal service-to-service authentication at Netflix runs on a private PKI called Metatron. Every workload gets a short-lived X.509 certificate, and services authenticate each other with mutual TLS. A workload cannot simply ask for a certificate. It is issued only after the identity service has satisfied itself that the requester really is the workload it claims to be. That verification step is called attestation. In each environment we support (VMs, containers, functions) attestation rests on some environment-specific proof that the platform can check on its own.The second concept is the Data Project, which is our unit of ownership for data. A Data Project owns tables, has a set of authorized users, and has an identity of its own. Jobs run as the Data Project rather than as the person who launched them. That is what keeps table-level access control and audit consistent across scheduled and interactive use.So the problem is this. A Spark job on managed compute starts with an AWS execution role and no internal identity. Everything it needs from inside the company (reading an encrypted column, evaluating table ACLs, holding an interactive session open longer than a short-lived token lasts) requires the internal one.One identity, one roleThe design rests on a decision made outside the Spark stack entirely. Each Data Project identity maps 1:1 to a dedicated IAM role, and the service that owns Data Project metadata records that mapping.The mapping is what makes translation possible. It lets a statement in the provider’s vocabulary (“this process is running as role R”) become a statement in ours (“this process is workload W”). Without it there is nothing to translate into, and no amount of cryptography helps. The hard part of bridging two identity systems is rarely the protocol. It is committing to a mapping and then keeping it authoritative.One practical objection arrives immediately. A single AWS account cannot hold tens of thousands of IAM roles, and we expect data projects in the order of ten thousands. We handled this by sharding data project roles deterministically across a small pool of dedicated accounts, which scales well past the projected number of projects and has the useful side effect of keeping workload roles on the far side of an account boundary from the control planes that launch them.ComponentsFive components take part.The control plane is the only service allowed to launch Spark jobs. It resolves the Data Project’s IAM role, builds and signs a workload metadata payload, and submits the job with that role as the execution role. It holds a signing key issued to it for this purpose alone.The Data Project service is the authority for the identity-to-role mapping.The Identity service receives attestation requests, verifies them, and issues certificates.A Spark plugin provides the hook. Spark 3.0+ added a plugin interface with driver-side and executor-side components that are initialized while those processes are bootstrapping.AWS STS acts as a notary, which is not its usual job.Step one: the control plane makes a signed claimWhen a job is submitted, the control plane validates the caller, looks up the Data Project’s IAM role, and builds a small payload describing the workload it is about to launch. The payload names the application identity, the mapped role, and the environment, stack and detail that the resulting credentials should be scoped to. The control plane signs the payload and passes it and the signature through as ordinary job configuration.Two properties of this step matter. First, only one service can produce a valid signature, so the set of things that can assert “this workload is legitimate” is small and auditable. Second, the payload is a claim rather than an authority. On its own it proves nothing, because job configuration travels through infrastructure we do not fully control and anything that can read it can replay it.Step two: the workload proves it holds the cloud identityWhen the managed service launches the driver process, it does so under an OS user that has the execution role’s credentials available. The driver-side plugin initializes and uses those credentials to sign, but not send, a request to the provider’s identity endpoint (sts:GetCallerIdentity). The result is a short-lived pre-signed URL.That URL is a transferable proof of possession. Anyone can fetch it. Only the holder of the role’s credentials could have produced it. And the response comes from AWS rather than from the workload, stating which role signed the request. The workload cannot lie about the answer because the workload does not supply the answer.The pattern is not new. It is the same idea behind AWS IAM authentication in HashiCorp Vault and in AWS’s own function attestation flows. It generalizes well: any environment that gives a process cloud credentials and nothing else can still produce a verifiable statement about its own identity.The plugin sends one attestation request carrying both artifacts, the pre-signed URL and the signed metadata.Step three: corroborationThe identity service does four things.It fetches the pre-signed URL against AWS STS and reads back the role that signed it. This is the provider’s statement.It verifies the metadata signature against the key issued to the control plane. This is the platform’s statement.It corroborates the two. The role AWS reports must be the role the control plane said it dispatched, for the identity the metadata names.It issues certificates for that identity, scoped to the environment, stack and detail from the signed metadata.Step 3 is the point of the whole design. Neither statement is sufficient by itself, and they fail in complementary ways. The provider’s statement is unforgeable but under-specified: it gives you a role, and a role is not a workload. It says nothing about why this process exists or what it should be allowed to be. The platform’s statement is well-specified but unverifiable on its own, for the reasons above. Put together, the signature says the workload was legitimately dispatched and the pre-signed URL says this really is it. Neither party has to trust the workload’s own account of itself.There is a tension here that we settled deliberately, and other teams should expect to meet it. The provider’s answer identifies a role, not an application. Deriving an application name from a role name is fragile string matching, and the session identifiers the platform assigns are not under our control. We chose to take the application identity from the signed metadata and use the provider’s answer only for corroboration. That costs a network round trip and a stricter signing requirement, and it buys a much clearer trust story.The fan-out problemA Spark application is one driver and up to thousands of executors, created and destroyed throughout the life of a job. Attestation designed around one process per host does not survive that.There are two defensible answers.In the first, each executor attests independently. This is uniform, adds no new trust boundary, and grounds every process’s identity in the same provider-verified proof. The cost is amplification. One large job can produce thousands of STS calls and thousands of attestation requests in a burst, which looks a lot like an attack and creates a hard dependency on provider-side rate limits.In the second, executors inherit credentials from the driver. The driver attests once and distributes credentials to executors over Spark’s internal RPC, which we configure with authentication and AES-GCM encryption so that only processes in the same application can take part. Load on the identity service stays constant. The cost is a second trust boundary and a driver that is now a credential distribution point.Considering our scale at Netflix here we went with the second approach. The general lesson is that identity amplification is a capacity question, and it is better to answer it on purpose than to have it answered for you during an incident.LifecycleCertificates are short-lived by design, so bootstrapping is only half the work. On self-managed hosts a system service handles renewal. Inside managed compute there is no equivalent hook, so the driver JVM runs a timer that re-attests on a fixed interval, well ahead of expiry. Credential material is written to a temporary directory readable only by the process owner and removed when the process exits.Executors do not refresh. They are usually short-lived, and an executor that somehow outlives its credentials can exit and be replaced, which is cheaper than making every executor a renewal client.The rule worth carrying into any similar system is that attestation has to be a repeatable operation rather than a bootstrap step. Anything that can only happen once at process start will eventually be the reason a long-running job dies nine hours in.Why this generalizesIf you run your own identity system and are moving workloads onto managed compute, the specific services here matter less than the shape of the solution.Anchor on one exchangeable primitive. A single authoritative 1:1 mapping between your identity and a provider identity is what makes translation possible. The rest is plumbing.Require two independent claims and corroborate them. One from the provider, unforgeable and under-specified. One from your control plane, well-specified and replayable. Trust the intersection and never either alone.Keep the signer scarce. If exactly one service can make the platform’s claim, your trust story fits in a sentence.Hook the layer you still own. On managed compute you rarely control the host or its init system, but you almost always control the runtime: a plugin, an agent, an entrypoint. Attestation belongs there.Decide the amplification policy on purpose. Distributed engines multiply every per-process operation by their parallelism.Make attestation repeatable and credentials short-lived. Renewal is a requirement, not a follow-up.What makes the result trustworthy is that no single participant issues an identity by itself. Not the workload, not the control plane, not the provider. And the workload, which is the party in the weakest position to be trusted, is never asked to vouch for itself.AcknowledgementsThanks to Amer Hesson for the Data Project abstraction, Nick Siow for the Data Project IAM role sharding, and Doug Clark for Metatron attestation.Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

💡 WHY THIS MATTERS FOR YOUR ROLE

The AI SDK is one of the most popular open-source AI projects in the world. It serves over 20 million npm downloads a week and the repo has over 26,000 stars. Maintaining the codebase means tracking four moving targets at once:Model providers: new providers, new capabilities, and new bugsUI frameworks: bindings for React, Next.js, Svelte, Vue, and othersSandboxes: the execution environments agents run code inHarnesses: adapters for Codex, Claude Code, Pi, and othersAfter multiple years of growth, the repo was getting 100+ new issues every month, and when Anthropic's Opus 4.6 model was released, PRs hit an inflection point. By late June, that compounding had accumulated over 1,000 open issues and almost 800 pull requests.That backlog is not a discipline problem. No maintainer, however good, can close that gap by working harder, and because generating code is cheap, it will only grow.Instead of trying to scale ourselves, we built a software factory. Four weeks in, it authors between 25 and 35% of PRs we merge and closes 70-80% of issues.Deciding what type of factory to buildBefore we built anything, we had to answer three questions:Why our existing approach using agents wasn't enoughWhat level of automation fit a project like the AI SDKHow to align automation and human effort to riskWhy not add more agents?The best maintainers are already using agents aggressively. Mitchell Hashimoto runs Ghostty with the goal of an agent always working, and encodes every agent failure in AGENTS.md so it never repeats. Simon Willison runs four coding agents in parallel, and review bots like Vercel Agent and CodeRabbit sit on millions of repos. Other maintainers like Daniel Stenberg have opted to block AI-generated submissions to curl.All of it helps, but none of it solves for the core constraint: every one of these solutions still routes every change through one human's attention. We believe that human accountability is still the core of trust in agentic engineering, so we knew our factory needed to solve for reviewer efficiency as a first principle.What kind of automation fits AI SDK?Software factories sit on a spectrum. At one end is full automation, where agents write, ship, and deploy without a human ever reading the code. In the middle are harnesses like Codex and Claude Code, where a person steers an agent or fleet of agents. At the far end is software you barely want to automate because the risk is too high, like firmware in a pacemaker or self-driving vehicle.The AI SDK needs to operate closer to the careful end. It is foundational AI infrastructure with millions of applications built on top, so quality and security are non-negotiable, and a human needs to have control over what ships. We needed our factory to heavily automate the lifecycle around the human, without removing them.How do we align automation and effort to risk?For a given change, the depth of human review needed scales with risk. Centralized roadmaps with detailed feature specs can define risk up front and directly shape the work going into a software factory. But open-source projects like AI SDK also get issues and pull requests from the community, and there is no guarantee they align with the goals of the project, or that changes are safe to make. Higher risk means human judgment is an even more critical part of the system.To optimize our factory for that judgment, we knew agents had to go beyond generating code based on a request; they needed to evaluate full units of work in the context of the entire project. Our goal was for the factory to generate a comprehensive assessment of each change for both fit and risk, including a full chain of documented evidence, making it easy for reviewers to apply the right amount of effort:Docs fixes get a quick glance for verificationWell-defined provider changes get focused validationA new public API gets deep reviewWhat we builtai-sdk-factory is a software factory that autonomously processes incoming issues and pull requests for AI SDK. Agents in the factory perform specific, reviewable tasks, like reproducing bugs, implementing features, and creating backports for older SDK versions. A human stays in control throughout the entire process, including merging every change.We didn't ship the factory in one swing. We built it incrementally, starting at the beginning of the process with classification of issues as bugs, features, or documentation updates. That first step not only gave us more visibility into the shape of the backlog, but also passed helpful context to the other specialized agents we built later.We prototyped multiple ways to build each new type of functionality, and in the process developed a set of guiding principles that shaped the architecture of the factory that went into production. Build one agent per taskOnce our classification agent reached a high level of accuracy, we focused on automating bug reproduction, fixes, and review of those fixes. We explored building a single agent equipped with skills for each step, but quickly realized that would come with a higher maintenance and troubleshooting burden over time. Instead, we built a single agent for each specific task, making every new capability easier to reason about, test in isolation, and debug. Each one is scoped to a specific job, with its own prompts, context, and evals. Today the factory has dedicated agents for every step in the flow:Bug reproductionBug fixesPR reviewsBackportsDocumentation updates Feature analysisFeature implementationSecure everything from the startWe implemented security with the second agent, because bug reproduction was the first step where the factory executed code based on content it didn't control.A factory operating on a public repository has to assume attacker-controlled input: every issue, pull request, comment, and the links inside them are untrusted. Because successful open-source projects are high-value targets, threats range from malicious code changes and supply chain attacks to resource exhaustion, API key exfiltration, and prompt exfiltration.Sandboxes are the foundation of our defense. Every agent in ai-sdk-factory runs inside an isolated Vercel Sandbox containing its code, its runtime, and only the secrets the agent's specific task needs. With those guardrails, untrusted content can shape what an agent proposes, but the damage any one task can do is contained to the sandbox.We also built a shielding layer around the sandbox that controls what agents can reach over the network, blocking the paths an attacker would use to pull secrets out of the isolated environment.The last line of defense is human review: nothing is merged without approval from a human on the AI SDK team.Build value locally, then move to the cloudThe first several agents we built for the factory ran through a local CLI. That enabled our team to iterate quickly as we noticed inaccuracies, felt friction, and prototyped different ideas. Once multiple steps were running reliably through the CLI, we were ready to move the system onto managed infrastructure. ai-sdk-factory uses: Vercel Functions for the API, workers, and webhook ingressVercel Queues for task executionVercel Blob for logsVercel Sandbox for the agent workspacesNeon Postgres for factory dataToday, GitHub webhooks feed the issue queue, and as soon as they arrive workers automatically pull them and kick off agent runs in sandboxes. We also built a monitoring UI that tracks every run in parallel, and visualizes the queue for the team of reviewers. Shipping software through our factoryOn July 24, a community member asked for blocked-domain support in OpenAI web search, and the request became issue #17898. The following section explains every step the software factory went through to process the issue, open a pull request with an implementation of the feature, and ultimately backport the merged feature to v5 and v6 of the SDK. ClassificationThe first agent that runs in the factory classifies issues and pull requests. In this case, the ai-sdk-factory bot commented on the issue and applied a label, identifying the type as Feature with high confidence. The agent included its rationale for the classification in the comment. AnalysisAfter classification, the analysis agent runs. Agents in the factory don't make any assumptions about the technical validity of a feature request or bug, so the analysis agent wrote a probe to confirm the absence of support for blocked domains. issue-17898-type-probe.ts was generated and run, and failed with an error when it looked for blocked-domains and didn't find it. The failing probe proved the feature was missing on main, and the agent included it in the analysis as evidence. The analysis agent then used the results of its investigation to build out a spec for the feature: add an optional blockedDomains filter to the existing web-search tool and map it to the provider's blocked_domains field.The agent also confirmed the spec fit the SDK's provider-adapter architecture and was backward compatible, and even scoped documentation changes. ImplementationAnother agent then implemented the spec and opened a pull request. The implementation agent ran a live end-to-end test, executing an OpenAI web search with wikipedia.org blocked and confirming the domain wasn't reachable. The test was included as additional evidence on the pull request. Automated reviewNext, a review agent scored the change, and when it didn't find any concerns, approved it. The agent rated the feature as fully implemented, with: Side-effect risk: lowPerformance risk: noneBackwards-compatibility risk: lowHuman reviewFinally, Lars read the chain of evidence from the agents, reviewed the code changes, and merged PR #18033 into main.BackportingOnce Lars merged the initial PR, ai-sdk-factory opened additional PRs for two backports, #18035 for v6 and #18036 for v5. The v5 backport did not apply cleanly, so the factory agent labeled and committed the conflicted state, identified and validated a fix, and pushed it seventeen minutes later. After review, Lars merged both backport PRs.ResultsWe are just over four weeks into running the software factory in production. Here are the results:PRs merged to mainBetween 25-35% of the PRs we merge on a weekly basis are now authored by ai-sdk-factory agents.BackportsFactory PRs are above 50% of weekly merges to the v6 release line, and v5 looks similar. Backports used to be work we skipped because dealing with merge conflicts wasn't worth the effort. v5 and v6 get far better support now.IssuesIn July, over 75% of closed issues were closed by the factory. Open issues fell from a peak of 1,022 in late June to 844 by early August, and open bugs are down roughly 25%.The ai-sdk-factory runs in public, so you can see every pull request it has authored on the repo.Improving the factory becomes the jobThe most interesting part of running the factory is what happens when it fails. Every run ends one of four ways: success, flawed, blocked, or manual. Only success ships, so the rest are signal that re-enters the system as feedback.A flawed run means an agent produced the wrong thing, and the fix is better prompts, better context, or a new eval case so the same mistake gets caught automatically next timeA blocked run means the environment was missing something, like a credential, a service, or a dependency, and the fix is provisioning itA manual run marks a boundary we drew on purpose, and forces us to ask whether improvements in the factory justify removing itEach of those fixes expands the automation boundary, and every week the factory can handle work that it couldn't be trusted with before.Running the factory is the same discipline teams already apply to their test suites and pipelines, but pointed at the system that does the work, instead of the system that checks it. In a world where agents define the SDLC, improving the factory will become the standard engineering job. Read more

💡 WHY THIS MATTERS FOR YOUR ROLE

Grasp the strategic implications, operational risks, and technical adoption velocity of Dots: Always-on agents for your organization.