The Agent Development Lifecycle has arrived on Cloudflare

From SDLC to ADLC: Managing Software at Agent Speed

For decades, software engineering has organized itself around the Software Development Lifecycle (SDLC): plan, design, implement, test, deploy, maintain, retire. That model worked when the most expensive step—implementation—was also the slowest. It no longer is.

AI has turned implementation into the fastest and cheapest phase. But that shift has simply pushed the bottleneck downstream. Maintainers face thousands of incoming pull requests and issues. Production engineers struggle to keep systems upright as delivery velocity climbs by orders of magnitude. The human-centric steps around implementation are now the constraint.

Why Agents Can't Just Write Code

No engineering manager would hire someone to write code and then expect another engineer to validate it, merge it, deploy it, hold the pager, and triage the resulting bugs. Yet that is how most organizations treat agents today. Models have improved dramatically, and agents can run over long time horizons—but they remain unevenly applied across the lifecycle.

Cloudflare treats agents as first-class customers. They can purchase domains, create temporary accounts, and exercise the full Cloudflare API. If agents are to manage the complete lifecycle on behalf of customers, they need the tools to do more than generate code. The company is introducing a set of primitives toward that end:

• @cloudflare/ci — a CI/CD runner built on Cloudflare Workflows that operates across millions of repositories, with self-healing behavior and the ability to spawn agents for complex tasks.
• OpenTelemetry traces in local development — observability parity between local and production environments, built into Wrangler and the Cloudflare Vite plugin.
• Cloudflare Agents and Agent Traces — a new surface for observing, maintaining, and improving agents, centered on OpenTelemetry trace data.
• AI-based engineering standards enforcement — Cloudflare's own system for applying best practices across product and system repositories.
• A software factory for Astro's issue triage — an automated system for triaging, reproducing, verifying, and fixing issues in a large open source project.

The Factory Model

There is a broader idea behind these pieces. Even with best-in-class automation, the SDLC's assumptions don't scale to the volume of code agents produce. Cloudflare argues the SDLC itself needs replacing with the Agent Development Lifecycle (ADLC)—a model designed for software factories.

The software factory concept is simple: an agent-driven system takes an input—a production error, a bug report, a feature idea—and handles the entire response autonomously. Today, that vision hits a wall. Most projects still require human-in-the-loop checkpoints at every lifecyle stage. Humans prompt agents, relay review feedback, and babysit a swarm of agents through the process. The factory model asks what would happen if the human only intervened where genuine judgment, taste, or inspiration is required.

A software factory must still cover the same stages as the SDLC, but it demands far more from its underlying platform. When an agent drives, every step that previously relied on a human must become:

• Programmatic — Click-based operations are non-starters for agents; every action needs a callable, debuggable, reliable API.
• Horizontally scalable — preview deployments shift from a convenience to a requirement; every agent needs a production-matching preview environment.
• Reproducible — bugs that surface only when simulating specific network conditions or device types must be addressable within the automation itself.
• Real-time and push-based — relying on humans to watch dashboards breaks down at agent speed; events must trigger work automatically.
• Atomic — each change must be independently testable, releasable, observable, and reversible without collateral effects.
• Permissioned — agents need an escalation path analogous to trusted humans having production SSH keys—without it, they cannot complete certain jobs.
• Self-improving — agents, like humans, need to learn from past on-call rotations and shipped features, getting faster and better over time.

The gap between a system that works 80% of the time and one safe for production workloads—some number of nines past 99%—is the same chasm autonomous vehicles had to cross. That is the standard for software factories as well.

Why a Standard CI/CD Pipeline Isn't Enough

Consider why you haven't yet let an agent auto-approve and merge its own pull requests to production services. The list of reasons grows with the stakes of the software. Shipping a small change to a dashboard can span roles, specializations, and organizational structures—and the subjective parts are the hardest to test or delegate. Traditional CI/CD pipelines, linear sequences in a YAML file, cannot represent that complexity.

Cloudflare's answer is to treat the pipeline itself as a Workflow. Cloudflare Workflows chains steps, retries failures automatically, and persists state across minutes, hours, or even weeks. Workflows can be defined dynamically, spawn agents or other Workflows, and manage containers and browsers. A Workflow can set feature flags for test users, inspect logs and traces, and monitor production metrics during a gradual rollout—everything normally outsourced to human judgment around a release.

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = await ci.runner({
      name: 'install',
      command: 'bun install --frozen-lockfile',
      cache: { inputs: ['package.json', 'bun.lock'] },
    });

    await Promise.all([
      deps.runner({ name: 'lint', command: 'bun run lint' }),
      deps.runner({ name: 'test', command: 'bun run test' }),
      deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
      deps.runner({ name: 'build', command: 'bun run build' }),
    ]);

    await deps.runner({
      name: 'deploy',
      command: 'bun wrangler deploy',
      cloudflareCredentials: {
        accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
      },
    });

That dynamic control extends to the prompts themselves. A Workflow can inspect incoming data—say, the past day's logs—and decide when and how to instruct an agent, passing context between steps:

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

The Full Lifecycle on One Stack

Once Workflows orchestrate complex steps and Artifacts serve as the storage layer for code, every stage of the development lifecycle has a home on Cloudflare:

The primitives are largely in place today. Some assembly is still required—Cloudflare continues to build and refine its own software factory on this foundation. But the company's position is that the stack is ready for organizations, from startups to large platforms, to build their own "machine that builds the machine." The starting points are @cloudflare/ci, building an agent on Cloudflare, and asking how much of the SDLC can be made autonomous.