Preview environments for agentic development

AI agents have made writing code fast and cheap. Verifying that code hasn’t gotten any faster.

Tests help, but they answer a part of a question: does this function behave? They don’t tell you that the changed API, the frontend, the database migration, and the feature flag all work together. For that, you need the change running somewhere real — with its dependencies, its config, and a URL you can click.

A preview environment solves this: a disposable copy of your application, wired to one pull request. These used to be a nice developer-experience perk. Now agents can open more pull requests than any team can hand-verify, and the preview environment is where that code proves it actually runs.

This post is about how I do that with Lifecycle, and about the new capabilities we built so that agents can use it as well.

---

Lifecycle is an open source tool that creates a preview environment for every pull request. When a PR opens, Lifecycle figures out which services the change needs, deploys them to Kubernetes, and posts stable URLs back to the PR. When the PR closes or the environment’s TTL expires, it cleans everything up.

I’m one of the contributors to Lifecycle, and I use it at work.

The core loop is simple:

1. Open a pull request.
2. Get a running environment with the services your change touches.
3. Share the URL with whoever needs to see it — designer, product, tester or an agent.
4. Close the PR, and the environment goes away.

That loop was built for people. The interesting recent work has been making it usable by agents too, through three surfaces: a CLI, a Model Context Protocol (MCP) server, and a built-in debug agent to assist engineers.

The CLI: lfc

lfc is the Lifecycle command-line interface, and it’s built for two audiences at once: people typing at a terminal, and automation — scripts and agents that run with no one around to answer an interactive prompt.

For people, it does what you’d expect — find the environment for a PR, watch a deploy, pull logs:

lfc builds find --pr 123 --repo org/repo
lfc builds status <uuid> --watch
lfc services logs <build-uuid> <name>

For agents and scripts,

• Every command supports --json, so output is structured and parseable.
• Interactive prompts appear only on a TTY. In a script or an agent loop, a command with missing input fails fast and names the missing flag instead of hanging.
• Destructive commands require an explicit --yes when there’s no human at the keyboard.
• lfc llms prints usage instructions written for agents, so a coding agent can teach itself the tool.

The benefit is an agent driving lfc gets structured output and predictable failures. It knows whether to retry, re-authenticate, or stop without guessing its way through browser use.

The MCP server

MCP is an open standard that lets AI tools call external systems through a common protocol. Lifecycle ships a remote MCP server, so coding agents like Claude, Codex or Cursor can query your preview environments directly instead of asking you to paste URLs and log fragments into chat.

Connecting is low-friction. Add lfc deployment’s /mcp URL to any of your MCP clients and sign in with your auth. The client uses OAuth discovery and registers itself automatically — you don’t create an OAuth client, an API key, or a token by hand.

Two things about the permission model are worth knowing:

• Your agent gets your permissions, nothing more. Lifecycle applies your existing user permissions to every tool call. Connecting an agent over MCP doesn’t grant access to any environment, repository, or site you couldn’t already reach.
• Write access is a policy decision that you control. The catalog includes management tools — creating, deploying, and destroying environments — but users control whether those are enabled at all. 

The current catalog groups its tools the way an investigation actually flows:

In practice, this means you can stay in your editor, ask your coding agent “why is the preview for my PR failing?”, and it can go figure it out.

Per-user connections for external MCP servers

MCP works in the other direction too. Lifecycle can act as an MCP client: an administrator registers an external MCP server — say, your observability or incident tool — allow-lists the tools agents may use, and those tools become available inside agent sessions.

The part that makes this usable day to day is per-user authentication. When a shared server needs individual credentials, each user connects it themselves: open Settings, open My connections, select the server, and complete the OAuth flow or enter the requested fields. Your next agent session picks up the connection automatically.

So the setup cost splits cleanly: the user integrates a tool and authorizes it once with their SSO/OAuth (several supported through Keycloak as the auth manager). After that, the tools are just there for an agent investigating your environment can also query the systems you’ve connected, with your identity and your access.

---

Your agent, or the built-in one?

A thread this week summed up a common view:

So many vendors are NOT getting this

I have one or two agents I use and like. For anyone else: give me an MCP interface to connect these agents to so I can use your service

Unless your a frontier AI lab, I prob don't want to use your agent, sorry https://t.co/8cMTKdFqwF

— Gergely Orosz (@GergelyOrosz) August 22, 2026

I agree, and that is what the CLI and the MCP server are for. If you already have an agent you like, point it at Lifecycle and keep your workflow.

The built-in debug agent covers a different case. It lives next to the environment, already has the logs and the Kubernetes state, and needs no setup. When a deploy fails and you want a quick answer or a one-off fix, you open it and ask.

Use both. Your agent, through MCP or lfc, for the work you own. The built-in agent for the quick debug.

The debug agent

The capability engineers use most is the built-in agent for diagnosing broken environments. Open an environment, ask why it failed, and the Lifecycle Agent starts with that environment already in context: the namespace, the deployed services, the build metadata, the logs, and the PR branch.

Here is one full run on a failed environment. The agent reads the build status, pulls the failing build job’s logs, checks recent Kubernetes events, and comes back with a diagnosis and a suggested fix.

For longer work, agent sessions keep the conversation going and can open an isolated workspace. Anything that crosses a write boundary like shell commands, git pushes, changes to the environment goes through approval users approval inline in chat. The conversation is durable; the workspace(sandbox) is released when you’re done.

Runtime backends

A short but useful detail: agent workspaces don’t assume one sandbox provider. Lifecycle supports multiple runtime backends — Kubernetes, OpenSandbox, E2B, Modal, and Daytona — with a capability matrix covering editors, previews, session resume, and prewarming. You pick the backend that fits your infrastructure and isolation requirements rather than adopting a new one.

Lifecycle sites

One more feature worth a mention: Sites. A site is a static HTML file or ZIP archive published at a stable Lifecycle URL — updates are versioned, and the URL stays the same.

If that sounds familiar, it’s the same idea trending in AI products right now — Claude Artifacts, ChatGPT Sites, Shopify Quick: hand someone a running, viewable page instead of a file attachment. Here it’s wired into your platform. An agent (or a CI job, or you) can generate a report, a prototype, or a docs preview and publish it with one lfc command or an API call, behind your deployment’s authentication.

How this changes the day to day

Putting it together, here’s the shape of the workflow:

1. An agent (or a human) opens a pull request. Lifecycle builds the preview environment.
2. A coding agent checks the environment over MCP or lfc cli to check if is it up, did the deploy succeed, what do the logs say?
3. If something’s broken, the debug agent investigates with the environment already in context, and shows its evidence.
4. Generated artifacts — reports, prototypes — get published as sites with stable URLs.
5. Anything that changes state goes through user permissions, administrator policy, and approvals.

The benefit is that verification stops being the bottleneck: the environment exists automatically, the agent can read it directly, and the humans spend their attention on judgment calls instead of tab-hopping between browser and tools to validate your changes integrated with the rest of your stack.

Code is getting cheaper to write. The apps are more interconnected and complex than ever. Preview environments keep those two from causing friction, and teaching the tools to speak agent, and agents to speak the tools, is how we keep up.

---

Lifecycle is open source: GitHub repo. Docs at uselifecycle.com/docs.