Execution Starts With the Right Artefact

TL;DR

• Delivery should start with the cheapest artefact that resolves the current uncertainty: a decision memo, prototype, eval, technical spike, or production-shaped pilot.
• AI-generated speed increases the need for explicit intent, quality gates, review capacity, permissions, and rollback.
• Readiness is proportional to consequence. Low-risk reversible work should move quickly; high-risk agentic work needs stronger evidence and controls.

---

Execution does not begin when a PM hands engineering a prototype. It begins when the team has enough shared understanding to make the next commitment responsibly.

That understanding may live in a narrative, a working flow, an eval set, a technical proof, or several of them. The artefact depends on the risk. The delivery discipline is making its meaning explicit, then carrying the intent through production without confusing generated completeness with readiness.

Four delivery principles

Small, independent changes

Reduce batch size. Small releases shorten the distance between decision and consequence, make rollback easier, and limit the number of assumptions moving together.

AI can generate larger changes quickly. Resist equating generation size with release size.

Instrument before exposure

Define how you will observe user behaviour, quality, cost, escalation, and failure before broad release. If a risk cannot be observed, it cannot be managed in production.

Preserve reversibility

Use feature flags, bounded cohorts, permission scopes, fallbacks, and rollback paths. The faster a team ships, the more valuable cheap recovery becomes.

Match rigour to consequence

A reversible internal summarisation tool and an autonomous credit decision should not share one approval path. Use the governance risk tier to determine evidence, review, and release controls.

Start with the artefact the decision needs

Delivery inputs should make the team's current understanding concrete.

A prototype is often useful. It is not automatically the source of truth. The team may need a short context document explaining the user, problem, constraints, alternatives, quality bar, and unresolved questions.

The modern standard is not “prototype instead of PRD”. It is “no ceremonial artefact”. Every artefact must earn its cost by resolving uncertainty or preserving intent.

State prototype maturity

Cheap implementation makes early prototypes look finished. Use explicit labels:

• Provocation: visualises an idea; assumptions remain open
• Interaction test: supports usability evidence; backend and economics may be simulated
• Capability test: includes real model behaviour; operating controls may be incomplete
• Production-shaped pilot: includes representative data, integrations, permissions, telemetry, fallback, and support for a bounded cohort

Place the label beside the demo. Include what is fake, missing, or intentionally out of scope.

This protects the team from the “it looks done” effect.

Write context that survives the handoff

AI-enabled teams need less translation and better context.

For material work, capture:

• The target user and situation
• The problem evidence
• The desired outcome and measurement window
• The quality standard
• Constraints and deliberate trade-offs
• Alternatives considered
• Known failure modes
• Decisions still open
• Accountable owners

This is smaller than many traditional PRDs and more useful than a prototype alone. It gives humans and agents the reasoning required to make local decisions without repeatedly escalating intent.

Keep it close to the work. Update it when decisions change. Stale context is worse than short context.

A risk-shaped Definition of Ready

Readiness should be additive. Every item needs a clear problem, owner, success condition, and safe path to change. AI-specific requirements increase with risk.

Do not demand a red-team report for a low-risk internal draft helper. Do not wave an autonomous payment workflow through because the prototype scored well offline.

Generated work changes review

When agents increase output, review becomes a delivery constraint.

Plan review mode with the work:

• Automated gate: deterministic tests and evals block known failures
• Sampled human review: risk-weighted inspection catches drift and unknown failure modes
• Full human approval: a named person signs off irreversible, regulated, strategic, or customer-sensitive actions

Generated code still needs architectural coherence, security, accessibility, performance, and maintainability. Generated analysis still needs source checking and assumption review. A passing test suite proves only what the tests express.

Estimate reviewer capacity. Forty generated pull requests do not create throughput if the team can responsibly review ten.

AI Productivity Is a Work Design Problem covers this capacity model in detail.

Delivery cadence in the agentic era

Keep ceremonies only where they support decisions.

Planning

Select the highest-value sequence of small bets. Confirm the current uncertainty, artefact, owner, review capacity, and release boundary.

Daily coordination

Surface blockers specific to AI systems:

• Eval regression
• Context or data gap
• Tool-call failure
• Permission mismatch
• Cost or latency breach
• Human escalation queue growth

Do not turn stand-up into a recital of agent activity. Report decisions and constraints.

Review

Show more than the interface. For AI work, review:

• Outcome evidence
• Eval performance and meaningful error categories
• Production traces where applicable
• User overrides and escalations
• Cost and latency
• Failure-state behaviour

A polished demonstration with no error analysis is incomplete.

Retrospective

Ask whether the team chose the right artefact, whether generated work exceeded review capacity, which context was missing, and what should become a reusable test or platform capability.

Progressive release

Autonomy should expand through evidence.

1. Run offline evals and deterministic tests.
2. Use shadow mode where the agent proposes actions without executing them.
3. Release to internal or trusted users with visible approval.
4. Expand to a bounded customer cohort with clear fallback.
5. Increase action scope only when quality, trust, economics, and operations support it.

Progression is not mandatory. Some workflows should remain assisted. The correct autonomy level is a product decision, not a maturity badge.

Delivery includes operations

An agentic feature is not complete when it deploys. It creates a living dependency on models, prompts, context, tools, credentials, evals, and human review.

Before release, name the outcome owner and system owner. Define who updates context, handles incidents, reviews escalations, and decides whether the agent should continue to exist.

Every Agent Needs an Owner provides the operating contract.

Cross-functional alignment without artefact theatre

Alignment should produce decisions, not documents for their own sake.

For complex work, maintain:

• A shared problem and outcome
• A decision log with owner and date
• A dependency map
• A current release boundary
• A source of truth for evals and operating controls

Use RACI or another ownership model when several teams share risk. A small team does not remove dependencies. It makes unresolved dependencies more visible.

Anti-pattern: production by visual inspection

The prototype works in the demo. The UI is polished. Stakeholders ask why it cannot ship next week.

The team has not tested representative failures, cost at volume, permissions, rollback, or the human escalation queue. None of that is visible in the prototype.

The correct response is not “engineering needs more time”. It is a concrete account of the gap between demonstrated interaction and operated product.

Execution makes that gap visible, closes it in risk order, and preserves the speed gained at the front of the cycle without borrowing failure from the back.

The next chapter, Go-to-Market, Launch, and Growth, covers how the product enters the market and earns continued adoption.