What running an Agentic Pipeline looks like

Definition is where the pipeline makes sure it understands the ask before anything is built on top of it. The same questions a developer would eventually raise on the ticket get asked now, in writing, while the request is still fresh. The person who filed it answers in the moment, instead of waiting days for someone to pick up the ticket and come back with questions.

The ticket says after the third paragraph. On a Politics feature the first three paragraphs often already hold a pull-quote or an embed, so does that mean the third paragraph of text, or the third block of anything?

The pipeline flags questions like this and looks for answers in the codebase and in the context files it keeps about how this site is built. Whatever it still can’t settle, it sends back to the person who filed the request, before a stakeholder is pulled in or a line is written.

Every team that can block a launch, ad operations, legal, whoever owns Core Web Vitals, usually isn’t in the room when the feature gets built, and surfaces the day before launch to explain why it can’t ship. The pipeline brings each in at the start as an agent, reading the ticket against its team’s own constraints and settling most conflicts straight from those guidelines. It only messages a stakeholder in Slack when the ticket genuinely needs them to approve something.

Here, that one is ad ops. No rule yet covers putting a unit in the slot above the first in-content ad, so the agent messages the ad-ops lead: this unit lands after paragraph three, above the first in-content ad on Politics templates. Confirm the placement, or give us the rule. They answer in a sentence, and it’s on the record for every later agent.

Before anyone designs a new thing, a handful of researcher agents fan out in parallel: one reads the existing codebase, one searches the plugin ecosystem for something off-the-shelf, others check the installed plugins for conflicts and read the architecture decisions already on record. They don’t all come back with a finding, and they aren’t meant to. The whole context, inside the repo and out, gets checked before a line is designed.

Two come back with something that matters. The codebase agent finds two pieces already in production: a newsletter block in the footer that posts to the email provider through an existing REST endpoint, and a consent-aware wrapper that holds third-party scripts until the visitor has accepted. The plan will reuse both, instead of writing a second sign-up path and a second consent check.

Another agent turns up something the ticket’s author didn’t mention: an A/B test the audience team ran last year on a different section, where the same kind of newsletter callout converted better three paragraphs from the bottom of the article than near the top. That cuts against after the third paragraph, and against ad ops, who want it high. It’s a call the pipeline can’t make on its own, so it puts last year’s result beside this week’s request and sends both to the editor to decide.

By now the answers exist, but they’re scattered: a confirmation in Slack, the standing guidelines each stakeholder team keeps, the editor’s call on placement. Requirements pulls them into one written definition of done. They harden into explicit acceptance criteria: the exact templates the unit appears on, what after the third paragraph resolves to when the first three already hold a pull-quote, what counts as consent before the email field is allowed to load, and the CLS budget the unit has to stay under.

The ambiguity a developer would otherwise resolve on their own, halfway through the build, is settled here and recorded, so the coding agent and the review agents later read the same definition of done.

With the acceptance criteria completed, the planner designs the smallest change that meets them, then checks it against the architecture decisions already on record. One says front-end consent always runs through the existing wrapper, and no feature sets cookies on its own (ADR-014). Another says in-content insertions go through the block insertion filter, never a hardcoded template edit (ADR-022).

The planner produces a sequence diagram of the unit’s render-and-consent path, and a human approves that diagram before any code is written.

The coding agent builds straight from the approved plan, reusing the pieces the research turned up. It writes the tests the spec calls for. This is the stage everyone pictures when they imagine AI writing code. It is the shortest part of the story, because the decisions that make code correct were already made.

The coding agent’s first pass renders the email field and loads the provider’s script on page load, the way most sign-up forms work. On a first visit from the EU, that fires before the visitor has accepted anything. It is a consent regression, and it is the kind that survives a quick human glance and resurfaces in an audit a month later.

A review agent catches it now, because it reads the diff against the team’s own consent standard, not a generic checklist. Beside the review agents, the scripted gates run: the linters, the tests, the build, passing or failing without opinion. An audit agent confirms the tests the coding agent claimed to write actually assert something. The fix is small: gate the field on the consent event, the way the existing wrapper already does it.

Your best engineer catches it on a good day. The agents don’t have bad ones.

The pipeline records a short narrated video of the finished output, placed where the editor decided and with the email field held until the reader consents. Alongside the video, it stands up a private, temporary copy of the site with the change already in place, so anyone can click through the real thing themselves.

Both go to the editorial and ad-ops Slack thread, the same people who raised the concerns at the start. They watch the clip, click around the preview, and either approve it or send it back with a note, without logging into WordPress or waiting for a test site to free up.

The last stage is the one that makes the next ticket cheaper. A human approves the consent fix from this run as a standing rule, and the pipeline applies it to every future ticket.

The constraints the team settled along the way are captured the same way, part of the context every agent reads on the next request.

In our pipeline, one of those overseers is the Requirements Watcher. It reads the Slack channels where tickets get discussed and decisions get made, and watches for changes that never reach Jira.

When the audience and editorial teams reopen the earlier A/B test in Slack and settle on moving the newsletter placement, that decision lives only in the thread. The Watcher sees the ticket doesn’t match, comments on it with both versions, and offers to update it. A person decides which version is correct.