Agentic delivery cadence: what runs daily, weekly, quarterly

In this lesson you'll learn:

• what runs at each of the six cadences, and who owns it;
• why proof runs on two triggers: every change and every week;
• how to set the whole rhythm up in week one, so nothing depends on memory.

Sound familiar?#

• The injection tests passed at launch and have not been run since.
• Drift gets checked when someone complains, which is weeks after it started.
• The maturity score on the slide is the one from the kickoff deck.

Each is a check that exists and has no clock.

What is an operating rhythm?#

A fixed schedule of checks, each with an owner and a dated artefact, so that loops close without anybody having to remember them. Ordinary software fails loudly: an error, an alert, a user who cannot log in. An agentic system mostly fails quietly: behaviour drifts with no deploy, a bill multiplies on flat traffic, an attack suite goes stale while it keeps reporting green. A check that runs only when someone notices a problem will run too late for every one of those.

Set up the six clocks, step by step#

Step 1 · Every day: build, integrate, review#

One bolt with one unknown, integrated the same day. The standup asks two questions: did yesterday's bolt integrate, and what is today's one unknown? Review depth comes from the most dangerous tool the change touches, via the path rule, never from the author. During a shadow run, QA reads agreement per slice every day. Owners: engineering lead, architect for the cut. Bolts vs sprints

Step 2 · On every change: prove it again#

Every prompt, model, tool or context change runs the harness per slice as a required check, and the injection suite: every attack string against every gated tool from every entry point. Pin the model version in each environment, so that a provider's update arrives as a change rather than as a mystery. Owners: QA lead for the harness and suite, DevOps for the pipeline.

Step 3 · Every week: watch what fails silently#

Chart the output mix against a week-on-week threshold and a frozen baseline. Run the injection suite on a schedule, with a date on it, even when nothing changed. Read the board's three numbers (review queue in days, same-day integration rate, cards in shadow and live) and count the defects that escaped the lane with no human reader. Owners: QA lead, DevOps, programme manager. Drift

Step 4 · Every cycle: report both numbers#

The saving and the spend on one line, with review hours and re-runs beside them, sent to the sponsor before it is asked for. The sponsor asks the four questions (which of these are rules, what may it do without a person, what are the two numbers, what level are we) in about ten minutes. Owners: product manager, sponsor. Measuring AI productivity

Step 5 · Every quarter: re-audit the controls#

Re-run the six-control maturity check by running each test, and expect the score to fall at least once. Extend the attack strings: a suite that has not grown in three months is testing last quarter's attacks and reporting green. Owners: sponsor for the check, QA lead for the suite. The maturity model

Step 6 · On an event: close the loops nobody waits for#

An incident gets a missing-control postmortem that ends in an enforced control and the next P0 brief. A surprise bill gets one question: which of the four signatures does the per-call log show? A drift breach re-opens the release gate by itself. These are the backwards loops; each needs a named owner before the event, not after it. The eight loops

Who owns which clock#

Where you'll use it#

• In week one, as the programme manager's setup checklist: every clock scheduled, every owner named.
• As the agenda of a weekly operations review: the drift chart, the attack run, the three numbers.
• After an incident, to find which clock should have caught it.

Why it matters#

The three loops with nobody waiting (cost, incident, governance) are exactly the ones that fail silently. A clock turns each into a routine with an owner; without one, each is handled once, by whoever happens to notice, and never fed back into the design.

Key takeaways#

1. Silent failures need clocks, not complaints: six cadences, each with an owner.
2. Proof runs on two triggers: every change, and every week even when nothing changed.
3. Every clock leaves a dated artefact, and the backwards loops are owned before the event.

FAQ#

How often should you evaluate an LLM application?#

On every change to a prompt, model, tool or retrieved context, through the evaluation harness per slice; and continuously in production, with the output mix charted weekly against both a weekly threshold and a fixed baseline.

How often should AI agents be tested for prompt injection?#

Weekly on a schedule, and on every prompt, tool or context change: every attack string against every gated tool from every entry point. Extend the attack strings at least quarterly, or the suite reports green against last quarter's attacks.

What meetings does an agentic AI team need?#

A short daily standup with two questions, a daily demo of the integrated bolt, a weekly operations review of drift and the board's numbers, a sponsor review each cycle with two numbers and four questions, and a quarterly maturity check.

How do you monitor an AI agent after launch?#

Chart its output mix weekly against two thresholds, keep a per-call log through one gateway for cost and routing, keep a redacted trace per consequential action, and wire a drift breach to re-open the release gate.

Apply it in your role#

Across the enterprise. Across a portfolio the clocks run on shared infrastructure, and a missed clock is an alert in its own right: the silent failure of the process, not only of the product.

The ten-minute workflow. Audit what actually runs on a clock:

Here is what we run and when: <list of jobs, meetings and reports>. Map it to the six clocks: every day,
every change, every week, every cycle, every quarter, on an event. List each check with no clock, each
clock with no owner, and each check whose last run is older than its clock.

Sources and credits#