APPLIED_PLAYBOOK: AGENTIC GOVERNANCE

Prompt Engineering vs Harness Engineering

A lifecycle governance playbook explaining why prompt engineering controls intent expression while Harness Engineering controls execution boundaries, evidence, rollback, and accepted outcome.
BACK_TO: PLAYBOOKSCONCEPT_CORE: AGENTIC LIFECYCLE GOVERNANCE
READING_ORDER: APPLIED_PLAYBOOK

Start with one question.

Prompt Engineering improves how intent is expressed to a model. Harness Engineering governs the execution boundary around agent work: context, authority, tools, evidence, plan/confirm/trace, rollback, remediation, configuration, and accepted outcome.

Read the playbook definitionReturn to playbooksOpen governance mappings
  1. 01Definition
  2. 02Scenario
  3. 03Inputs and outputs
  4. 04Failure modes
  5. 05Evidence required
  6. 06Sources
DEFINITION

Prompt Engineering improves how intent is expressed to a model. Harness Engineering governs the execution boundary around agent work: context, authority, tools, evidence, plan/confirm/trace, rollback, remediation, configuration, and accepted outcome.

Why ordinary model/tool governance is insufficient

Prompts can guide behavior, but they are not evidence chains, accepted outcomes, rollback protocols, authority records, or remediation closure. Treating prompt quality as governance leaves lifecycle responsibility outside the system.

Source context

This playbook applies lifecycle-responsibility questions to the stated scenario. Its relevant responsibility objects are Intent object, Context boundary, Authority boundary, Evidence chain, Accepted outcome, Substitution record, Remediation closure. The page is an author-analytical guide and does not add scores, legal conclusions, certification, or vendor assessment.

AI Agent LifecycleAuthority BoundaryHarness Engineering for AI Agents

Scenario and distinctive question

Question: Which responsibilities belong in prompts, and which must be enforced by the execution harness?

Scenario: An AI team reviews a workflow where prompt instructions are strong but tool authority, evidence, rollback, and acceptance remain implicit.

Inputs

  • Prompt intent and constraints
  • Harness policy and tool scope
  • Required evidence and acceptance criteria

Outputs

  • Prompt-versus-harness responsibility split
  • Control placement decisions
  • Evidence and rollback requirements

Lifecycle governance checklist

  1. Use prompts to express intent, constraints, and desired reasoning posture.
  2. Use harness boundaries to control context, tools, action scope, and confirmation requirements.
  3. Treat prompts as inputs to the lifecycle, not as the lifecycle record.
  4. Capture evidence outside the prompt so review, replay, dispute, and remediation remain possible.
  5. Define accepted outcome outside the prompt as a human or organizational responsibility state.
  6. Define rollback and remediation as lifecycle transitions, not as another prompt attempt.
  7. Record model, prompt, tool, runtime, or harness substitution as a governance event.

Failure modes to test

  • Prompt text is treated as an audit record
  • Acceptance is delegated to model output
  • Rollback is attempted through another prompt

Evidence required for review

  • Prompt version and intent
  • Harness policy snapshot
  • Tool authorization trace
  • Acceptance and remediation record

Related Missing Regulatory Objects

Intent objectContext boundaryAuthority boundaryEvidence chainAccepted outcomeSubstitution recordRemediation closure

RCCS-M / ALCS relevance

RCCS-M is relevant because prompts alone do not express the full lifecycle object layer. ALCS is relevant because intent, authority, evidence, acceptance, dispute, remediation, and closure must remain coherent after execution begins.

Protocol path: MPLP as one option

MPLP is one protocol path for expressing lifecycle responsibility semantics around harnessed agent work. It is not required, exclusive, certified, regulator-approved, or already an industry standard.

Boundary statement

This playbook is an author-analytical governance guide. It is not legal advice, legal compliance proof, certification, regulator-approved guidance, vendor ranking, procurement recommendation, or a claim that prompt engineering is obsolete.