How to Ship More With AI Agents: The 2027 Checklist

In 2026 most teams gave an AI agent write access to something: the website repository, the ad accounts, the CMS, the newsletter. The agents were fast. A meta title rewrite, a new landing page section or a budget shift took minutes instead of a ticket in someone's queue.

Most of those teams didn't ship much more. The work moved somewhere else.

The bottleneck moved from writing to checking

Every change has three questions attached to it, whoever wrote it:

1. Before it goes live: does it break anything?
2. After it goes live: did it do what it was supposed to?
3. Later: who looks at it again next week, and who tells people about it?

When a person makes two changes a week, they answer all three in their head. When an agent makes twenty a day, a person still has to answer all three for each one, and that person is now the limit. Either they check everything and the agent waits, or they stop checking and find out from a customer that the pricing page has been down since Tuesday.

Teams that ship more with agents in 2027 won't be the ones with the fastest agent. They'll be the ones where the three questions are answered without a person doing it by hand. That is what this checklist is for.

The checklist

Before it ships

1. Brief the agent on your stack, in a page it can read. Most agent mistakes aren't bad code. They're wrong assumptions: it suggests a setting from a different host, or a variable it can't see. A short page that says how builds, deploys and settings work in your setup removes a class of mistakes before they start. In Cogny: tell your coding agent to read cogny.com/sites.md before it touches hosting. It covers builds, what an app needs to run, variables versus secrets, domains and the tools below.

2. Every change is a pull request with its own preview. A change nobody can open before it merges has to be trusted blind. A preview turns "looks right in the diff" into "works in a browser". In Cogny: every pull request on a Cogny Sites site gets its own preview deployment, and its address is posted on the pull request.

3. The agent can see what actually happened. An agent that can only read the repository guesses why the live site misbehaves. Give it the build errors, the logs and what the running site has. In Cogny: get_site shows recent deployments with their build errors and which variables the running site has (names only, never values). get_site_logs shows what the live site or a preview printed. On Cloud, Cogny's coding agent can also fix failed builds on its own pull requests (Settings → Cogny Code → Fix Builds).

4. Write down the pages that must never break. "The site works" isn't checkable. "/, /pricing, /signup and /api/health answer 200" is. Writing that list once is the cheapest safety step you can take, and it keeps paying on every deploy. In Cogny: add .cogny/smoke-urls.txt to the repository, one row per page with the status it must answer, for example /pricing 200 or /login 200 /auth/signin. Up to 100 rows.

When it ships

5. Check every deploy before visitors get it. A change can pass every test and still fail in production: a missing variable, a page that only breaks with real data. The fix isn't more tests. It's making a new version prove itself before it takes traffic. In Cogny: every production deploy on Cogny Sites starts next to the live version without visitors. It goes live only when the home page answers without a server error and every page in your smoke list answers as listed. If anything fails, visitors keep the version that works, and the deployment says which page failed and what it answered. A passing check adds about 20 seconds. How the deploy check works.

6. Decide in advance which changes may merge without a person. If every pull request waits for a person to press Merge, a one-line copy fix waits as long as a billing change. Write the rule down: what may go through on its own, and what always waits. In Cogny (Cloud, GitHub): auto-merge is off until an owner or admin turns it on. When it's on, the coding agent's own pull requests merge only when every check passed, the change is at most 15 files and 400 changed lines, it doesn't touch migrations, CI, deploy or environment files, and Cogny's merge review scores it at or above your threshold (default 90). You can add a policy in plain words, like "Hold anything that touches billing or sign-in". Every decision is posted on the pull request. Auto-merge.

7. Keep a person on every write from your own AI client. Speed doesn't mean nobody looks. When your own assistant changes an ad account or a CMS, the assistant's "ask before running" prompt is the approval step. Keep write tools set to ask every time. In Cogny: writes from your own AI client run when the client sends them; Cogny does not hold them for a second approval. Inside the Cogny app, write tools ask first by default. Who approves a write.

After it ships

8. Record every change, not just the launches. This is the step most teams skip, and every later step depends on it. A budget move, a paused keyword or a rewritten headline is invisible a week later unless something wrote it down, with when and why. In Cogny: every change your agent makes through a connected platform is recorded on a ticket by Cogny itself, on every plan: campaigns, ads, posts and pages, and also budgets, bids, statuses, keywords, targeting and Tag Manager edits. Changes from the same person and assistant within two hours share one ticket. Nothing depends on the agent remembering to log its work.

9. Give every change its own verdict. "Leads went up this week" doesn't tell you which of the ten changes did it, or which one cost you. Judge each change on the numbers it should have moved. In Cogny: three to seven days after a change, Cogny compares the numbers before and after it on your own KPIs and marks it worked, didn't work, hurt or inconclusive, with the number it was judged on ("Leads: 40 → 22"). Your agent reads them with get_my_impact. Free and Solo measure 3 tickets a month; Cogny AI, Cogny Pro and Cloud measure every one. Every change gets a verdict.

10. Book the follow-up when you make the change. "I'll check it on Thursday" is the step that gets dropped. So is "once it's live, post about it". The moment to book the follow-up is when the change is made, while the context exists. In Cogny: with schedule_ticket an agent books one run for later, at a time up to 180 days ahead or a set number of minutes after a code ticket's pull request merges, with full instructions and only the tools you pre-approve. "20 minutes after this merges: check the FAQ is live, post one line about it, submit the URL" is one call. On Solo, Cogny AI, Cogny Pro and Cloud with Automations on. Scheduled follow-ups.

11. Turn the work you repeat into a loop. The weekly search term cleanup, the Monday numbers, the monthly content refresh: if an agent does it the same way every time, schedule it instead of asking again. In Cogny: Loops run an agent on a schedule with the tools you grant it, and each run is a ticket that gets measured like any other. Up to 5 on at once on Solo, Cogny AI and Cogny Pro; on Cloud with Automations on.

12. Let the agent report what's broken. When a tool fails or is missing, the slowest path is the agent telling you and you writing to support. Let the agent file it with the error it got. In Cogny: report_bug, request_feature and contact_support are tools your agent calls itself, and Cogny's answers come back to it.

The checklist, short

Where to start

You don't need all twelve on Monday. Two give the most back for the least work:

• Item 4 and 5: write your smoke list. Ten minutes, and from the next deploy a broken page never reaches visitors.
• Item 8: connect your platforms and let your agent work through Cogny. From then on every change is on record, and the verdicts start arriving within a week.

Connect your agent with npx @cogny/cli init in a coding agent, or add https://app.cogny.com/mcp as a connector in Claude or ChatGPT. The install guide covers both, and the buying guide lists what each plan can do.