GOVERNANCE FROM THE START

Good prompts deserve
good engineering.

A prompt can influence a decision, a tool call or a proposed change. Manage that influence early, while the workflow is still small enough to understand.

01

Ownership & purpose

Name an owner. Define the problem, intended audience, permitted context and expected output. Make the prompt’s role in the workflow explicit.

02

Versions & review

Record prompt changes in version control. Review the diff, the rationale and the associated tool permissions before releasing a new version.

03

Evaluation & evidence

Use representative examples, including missing data and failure cases. Check usefulness, unsupported claims and whether escalation boundaries are respected.

04

Release & recovery

Record the approved prompt version alongside the model configuration and tool contract. Retain a known-good version and a way to pause the workflow.

05

Context & separation

Keep client, personal and work contexts scoped. Treat retrieved documents and task notes as input data, with provenance, rather than new authority.

06

Permissions & budgets

Enforce scoped access, time and cost limits outside the prompt. Distinguish read, propose and execute. Make cancellation and human escalation practical.

A SMALL REGISTER, A BIG DIFFERENCE

Know what is running.
Know who owns it.

A prompt register gives reviewers a common reference. It should travel with the workflow rather than disappear into an individual chat.

Prompt
Service investigation
Version / owner
v1.3 / Engineering lead
Tools
Approved read-only evidence
Expected result
Diagnosis + source references
Decision gate
Human review before any change
Release evidence
Evaluation record + reviewed diff

Instructions alone cannot enforce control.

A prompt can describe a boundary. Tool services, identities and execution policy must enforce it. Add attribution, audit records and explicit approval for the actions that need it, then test those controls independently of the model.

WHY START EARLY?

Small changes can
change the whole workflow.

As prompts, models and tools evolve, the same task may produce a different proposal. Early governance gives the team a way to understand those changes and decide which behaviour to release.

Define a reviewable contract.

Capture the prompt’s purpose, the inputs it may use, the output a reviewer expects and the conditions that require escalation. Link that contract to the permitted tools and the person who owns the workflow.

For an investigation prompt, the contract might require a diagnosis with source references, a list of uncertainties and a proposed next check. Missing evidence should be visible in the result.

Exercise the awkward cases.

Try stale documentation, contradictory logs, incomplete task records and a requested action outside scope. Retrieved material can contain misleading instructions; it should remain evidence to assess, rather than authority to change the workflow.

Repeat the relevant checks when a prompt, model configuration or tool contract changes. Retain the reviewed version and its evaluation record so a release can be compared with what came before.

PRACTICAL GOVERNANCE QUESTIONS

Make the boundaries
easy to understand.

Does every step need a human approval?

The workflow owner can pre-authorise bounded, routine steps under an explicit policy. Decisions with wider consequences need a review point appropriate to their scope. Enforce the boundary in the tool or execution service and give people a practical way to pause work.

How much process does an early pilot need?

Start with a named owner, an approved prompt version, a short set of representative checks and a clear record of permitted actions. Add controls as the scope and consequences grow. The first pilot should already have a way to stop and a way to evaluate its result.

Can another agent review the first agent’s work?

A second agent can challenge assumptions and check references, but may repeat the same mistake. Give the reviewer access to the underlying evidence and preserve disagreements. The workflow’s acceptance criteria and human decision points still apply.

LET’S FIND YOUR FIRST WORKFLOW

Start with a real
engineering problem.

Start a conversation