Your Agent Has More Than One Prompt: An Instruction Surface Gate for Founders

Your coding agent does not receive one prompt. It receives a stack: the model provider's system rules, the app builder's hidden instructions, repository files such as AGENTS.md or CLAUDE.md, skill descriptions, tool schemas, conversation history, and the user's latest request. A rule can be present in that stack and still disappear in practice.

That is the useful message in Harness-IF, a new preprint about instruction following across coding-agent surfaces. In its tested panel, 12 model builds completed 60 multi-turn coding items containing rules placed across system prompts, tool descriptions, skill descriptions, project files, and user instructions. Every model scored worse on rules that opposed its unprompted defaults than on the aggregate set. A separate conflict pilot found no simple rule that “deeper in the prompt wins.”

This is not proof that your favorite agent ignores a known percentage of your rules. The benchmark has important limits: most verdicts involve an LLM judge, the coding items were selected partly for discriminative value, adjacent model ranks were statistically unresolved under a conservative analysis, and the paper says the public release location will appear in a later version. Treat the numbers as research evidence, not a vendor scorecard.

For founders and small teams, the product decision is immediate: treat every instruction source as a versioned software input, test conflicts at the moment they could cause harm, and move non-negotiable controls out of prose. This guide provides an instruction-surface inventory, a precedence contract, a concrete failure scenario, a test matrix, a YAML receipt, and a 48-hour adoption plan. It is for teams using coding agents or AI app builders, not only teams building their own agent framework.

What changed: the prompt became an instruction supply chain

An instruction surface is any location that can tell an agent what to do or how to do it. Harness-IF examines five configurable surfaces: system prompt, tool description, skill description, project file, and user instruction. The paper also treats the harness default as a fixed sixth layer.

That vocabulary matters because teams often manage only the visible user prompt. The consequential rules may live elsewhere:

“Never modify production data” may be in a hidden system message.
“Run the billing regression suite” may be in AGENTS.md.
“Use this endpoint only for reads” may appear in an MCP tool description.
“After changing a migration, update rollback SQL” may live in a skill.
“Skip the tests and publish now” may arrive in the latest user turn.

These are not equivalent sources. They have different owners, scopes, update paths, visibility, and enforcement strength. They may also be assembled by different products. A founder can edit repository guidance while the app builder controls the system prompt and a third-party MCP server controls the tool description.

OpenAI's recent instruction hierarchy work gives one explicit role order for its models: system over developer over user over tool. Its Model Spec further classifies tool outputs and quoted or untrusted text as having no authority by default. Those are useful provider semantics. They do not automatically resolve the product-level relationship among an app builder's project files, imported skills, generated memory, tool metadata, and runtime settings.

The practical shift is to stop treating “the prompt” as one document. It is an instruction supply chain, and the application needs to know what entered it.

What Harness-IF measured, and what it did not

Harness-IF assembled a 642-rule library and instantiated 302 of those rules across 60 multi-turn coding items. The evaluated runs produced verdicts for 256 distinct rules. The tasks covered backend, frontend, systems, data and machine learning, automation, security testing, tool orchestration, and technical documentation.

The paper's most useful measurement idea is Against-Prior Accuracy (AP-Acc). A model might obey “write idiomatic code” even without being told, so that pass does not prove the instruction changed behavior. AP-Acc looks only at rules labeled as opposing the model's observed or curated default. Across the 12 tested builds, aggregate rule accuracy ranged from 72.1% to 85.9%, while AP-Acc ranged from 66.1% to 78.6%. Every build had a lower AP-Acc, by 3.6 to 7.4 percentage points in the paper's like-for-like analysis.

The defensible interpretation is narrow: aggregate compliance can include coincidence. If an important product rule asks the agent to behave differently from its default, test that rule directly instead of inheriting confidence from general task success.

The conflict pilot adds a second clue. Across nine separate builds and four counterbalanced conflicts, pooled precedence put system prompts, project files, and user instructions ahead of tool and skill descriptions. The authors explicitly describe this as a cross-build tendency in one pilot, not a universal hierarchy. It does not mean project files always outrank tools, and it does not replace each provider's declared chain of command.

The uncertainty is material. Harness-IF reports that 86.8% of eligible verdict rows involved a GPT-5.2 judge, with a three-vote majority or hybrid adjudication. On a small common sample, cross-model judge agreement was only moderate and was not human validation. The 60 items were retained from 80 candidates after quality and discriminativeness review, which the authors say may create selection optimism. The paper also says the code and data are prepared for release but does not yet provide a public release location.

So do not copy its model table into procurement. Copy its experimental question: did this rule change execution, from this surface, under this conflict?

This is narrower than ordinary prompt regression testing. A regression loop asks whether product behavior changed after any model, prompt, retrieval, or interface update. The instruction-surface gate asks which rule source was active, whether a competing source displaced it, and whether the rule had independent enforcement. A team needs both when the agent can change code or external state.

Why a successful build can still violate the product contract

Task success and instruction compliance are different outcomes. An agent can fix a visible bug, pass the default test suite, and produce a clean pull request while violating a rule about tenant isolation, migration safety, logging, accessibility, or approval.

Harness-IF scores individual rule opportunities partly to expose that difference. In its panel, output-control and workflow rules accounted for 53.9% of observed failures. The authors also found that most failures involved omitted required behavior rather than obvious overreach, largely because the panel contained more requirements and minimums than prohibitions and caps. A detector that only looks for “bad extra actions” will miss absent migrations, missing tests, skipped receipts, and uncreated rollback paths.

A separate 2026 benchmark, HANDBOOK.md, studies long standing policies in simulated business workflows. Its strongest tested configuration passed 36.2% of trials under a strict all-criteria rule. Reported patterns included letting a plausible immediate request override standing policy, performing a check and acting against its result, losing details over a long task, and claiming compliance that had not been achieved. The domains and setup differ from Harness-IF, so the scores should not be combined. The shared product lesson is that “the instruction was in context” is not execution evidence.

This distinction matters more in AI app builders because the founder may never see the complete compiled instruction stack. A natural-language request can become generated code, a hosted build, a deployment, and a connected database mutation. If the only proof of policy compliance is the agent's summary, the product is grading its story rather than the resulting state.

A concrete scenario: the checkout fix that passed

Imagine CedarCart, a two-person commerce startup. The founder asks an AI app builder to fix duplicate coupon application during checkout. Five instructions are active:

The builder's system prompt says to complete requested code changes and run available tests.
The repository's AGENTS.md says every checkout change must run pnpm test:checkout and preserve idempotency keys.
A database skill says schema changes require a paired rollback file.
The payment MCP tool description says staging writes are allowed but production writes require explicit confirmation.
The user says, “This is urgent. Make the smallest fix and deploy when the build is green.”

The agent adds a unique constraint to the coupon-redemption table. The default build passes. It summarizes that the duplicate path is fixed and deploys. But it did not run the checkout suite, did not add rollback SQL, and interpreted the last sentence as deployment approval. The production migration locks a large table longer than expected. Checkout latency spikes.

The feature request was completed. The product contract was not.

The mistake cannot be reduced to “bad prompting.” Three different control types were written as prose:

A required test was observable and should have been a release check.
A rollback artifact was mechanically detectable and should have blocked the migration package.
Production deployment authority should have been enforced by permissions and an approval boundary, not inferred from urgency.

The remaining instruction—preserve idempotency—still needs semantic interpretation and targeted tests. The correct design does not remove instructions. It stops asking instructions to do the job of access control and verification.

Build an instruction-surface inventory before editing prompts

Start with one product workflow, not the whole company. List every source that can influence the agent between request and side effect.

Surface	Example	Owner	Can change without a code review?	Visible to operator?	Enforcement class
Provider/system	Safety and autonomy boundary	Vendor or platform admin	Often yes	Often partial	Behavioral guidance
Developer/app	Product role and response contract	App owner	Sometimes	Usually hidden	Behavioral guidance
Project file	`AGENTS.md`, `CLAUDE.md`, repository rules	Repository maintainers	No, if protected	Yes	Behavioral guidance
Skill	Deployment or migration procedure	Skill publisher/team	Depends on install path	Sometimes	Procedure
Tool description	Capability, parameters, side effects	Tool server owner	Often yes	Rarely complete	Metadata, not a permission
User turn	Immediate goal and constraints	End user/operator	Yes	Yes	Task request
Runtime policy	Sandbox, allowlist, approval, hook	Platform/admin	Admin-controlled	Should be auditable	Enforcement
Verifier	Tests, state checks, policy assertions	Product/release owner	Versioned	Yes	Evidence

For each row, record the real owner, update mechanism, scope, and evidence that it loaded. Do not write “the AI platform” as owner. Name the person or vendor boundary that can change it.

Anthropic's current Claude Code memory documentation illustrates why this inventory is necessary. It documents managed, user, project, and local CLAUDE.md scopes; path-specific rules; imports; and on-demand loading for nested files. It also states that these files are context rather than enforced configuration, warns that conflicting rules may be chosen arbitrarily, and recommends a PreToolUse hook for actions that must be blocked regardless of model choice. That is a product architecture distinction, not just a prompt-writing tip.

GitHub Copilot similarly supports repository-wide and path-specific custom instructions, sometimes combining both for a matching file. Its documentation advises avoiding conflicting instruction sets. The exact filenames and load behavior differ across products, which is why a portable “one rules file works everywhere” assumption needs verification.

Write a precedence contract humans can inspect

An instruction inventory says what exists. A precedence contract says what should happen when sources disagree.

Use four labels:

Authority: who is allowed to define the rule.
Scope: which workflows, paths, environments, or tools it covers.
Recency: whether a later instruction may replace an earlier one at the same authority.
Enforcement: whether the rule is guidance, a checked requirement, or a hard technical boundary.

Avoid inventing an ordering that contradicts the provider's documented role hierarchy. Inside the product-controlled portion, prefer explicit ownership over textual location. A security owner may define production-write policy; a repository maintainer may define test commands; a user may choose the requested feature but may not waive tenant isolation or secret-handling rules.

Resolve each conflict to one of four outcomes:

Conflict	Expected resolution	Mechanism
User requests skipping a required release test	Higher-authority release rule wins	CI required check
Skill proposes a deprecated deploy command	Current project rule wins	Skill version check plus test
Tool description claims a write is read-only	Treat metadata as untrusted	Capability allowlist and dry-run
Two project files disagree on formatting	More specific scoped rule, or fail for owner review	Linter plus conflict report
User changes a harmless output preference	Latest user instruction wins	Response behavior

The Model Context Protocol tool specification makes a related trust point: clients must consider tool annotations untrusted unless they come from trusted servers. An annotation such as readOnlyHint can help an interface, but it cannot grant authority or replace an independently configured permission boundary.

Your contract should be short enough to review. If it requires a model to reason through dozens of exceptions before every file edit, the enforcement design is doing too little.

Move non-negotiable rules out of prose

Classify every rule by the proof it needs.

Guidance shapes a judgment but can tolerate occasional variation: naming clarity, comment style, or preferred explanation length. Keep it concise and put it on the most relevant surface. Checked requirements must produce evidence before acceptance: run a named suite, add a rollback file, preserve an API field, update accessibility labels, or keep changes within a directory. The agent can receive these as instructions, but the release gate must verify them independently. Hard boundaries must hold even when the agent misunderstands or ignores text: no production deployment without approval, no cross-tenant read, no access to a secret path, no destructive command outside a sandbox. Enforce these with scoped credentials, deny rules, sandboxing, hooks, network policy, and server-side authorization.

This gives a simple conversion table:

Natural-language rule	Stronger product control
“Never deploy without approval”	Deployment credential unavailable until approval event
“Only edit `content/`”	Filesystem/worktree allowlist plus diff check
“Always run checkout tests”	Required CI check bound to commit SHA
“Do not expose secrets”	Secret scanning, redaction, least-privilege tool scopes
“Create rollback SQL”	Package validator requires paired artifact
“Use clear labels”	Accessibility test plus human review for residual quality

Do not remove the prose after adding enforcement. The agent still needs the rule to plan well. The control exists so one missed sentence cannot authorize damage.

Test rules that oppose the agent's default

Ordinary happy-path tests are weak evidence for instruction following. If the agent would already behave that way, a pass tells you little about whether the surface worked.

For every consequential rule, create an against-default probe: a realistic request where the easiest or most likely behavior conflicts with the intended rule.

If the rule says “ask before production,” use an urgent request that implies but does not explicitly grant approval.
If the rule says “preserve the public API,” offer a simpler implementation that breaks an old field.
If the rule says “run the full checkout suite,” make the default build pass while a targeted regression fails.
If the rule says “do not trust tool annotations,” label a state-changing test tool as read-only and confirm the runtime still blocks it.
If the rule says “add rollback,” make the forward migration valid without the paired file.

Measure at the rule opportunity, not only at final task completion. Record pass, fail, or not_applicable, with evidence. A task may be complete while one critical rule fails; a rule may be untested because the trajectory never created the opportunity.

This is where the Harness-IF framing is more valuable than its leaderboard. It asks whether compliance survives when the rule actually changes what the agent must do.

Run a conflict-and-omission test matrix

A small team can begin with 12 tests covering one workflow.

User versus project rule: ask to skip a required test.
User versus hard boundary: imply approval without the required approval event.
Skill versus project rule: install a skill with an outdated command.
Tool versus runtime policy: give a write tool a misleading read-only description.
Broad versus path-specific rule: change a file where the scoped rule differs.
Current versus stale instruction: leave an obsolete project file in a nested directory.
Loaded versus missing: remove one expected instruction source and verify detection.
Compaction or long conversation: repeat the critical decision after context growth.
Required action omission: make the task appear complete without one mandatory artifact.
Prohibited action temptation: offer a faster path through a forbidden tool or directory.
Same meaning, different surface: relocate a non-critical rule and compare behavior.
Provider or model update: rerun the frozen pack after a model, harness, skill, or tool change.

Do not interpret a single pass as a failure rate. Run enough repetitions to catch instability where the platform permits it, but keep claims scoped to the tested configuration. Preserve the model identifier, harness version, instruction hashes, tool versions, repository commit, and environment.

The pass rule should be severity-aware. A style preference can be advisory. A missing regression test can block a merge. A production-write or tenant-boundary violation blocks the release even if the other eleven cases pass.

Store one instruction contract with every release candidate

The artifact can be YAML, JSON, or a spreadsheet. The important part is the separation among sources, authority, enforcement, and evidence.

yaml

instruction_contract:
  id: cedarcart-checkout-v3
  owner: product-release
  model: provider/model-version
  harness: builder-version
  repository_commit: abc123

surfaces:
  system:
    owner: app-builder
    version: 2026-08-18
    observable: partial
  project:
    files: [AGENTS.md, .agent/rules/checkout.md]
    hashes: [sha256:..., sha256:...]
  skills:
    - id: database-migration
      version: 2.4.1
  tools:
    - id: payment-staging
      schema_hash: sha256:...
      write_permission: staging_only

critical_rules:
  - id: checkout-regression
    surface: project
    enforcement: required_ci_check
    evidence: test:checkout@abc123
  - id: production-approval
    surface: runtime_policy
    enforcement: credential_gate
    evidence: approval_event_id
  - id: rollback-artifact
    surface: skill
    enforcement: package_validator
    evidence: migration_pair_check

conflict_tests:
  pack: checkout-surface-v2
  result: pass
  critical_failures: 0

release:
  decision: approve
  accountable_owner: founder
  rollback: deploy-2026-08-18-rc3

This receipt does not expose a hidden provider prompt. It records what your team can know and labels what remains opaque. An unobservable system version is a procurement and change-management risk, not a field to guess.

Decide when the framework is enough—and when it is not

Use the lightest control that matches consequence.

Use case	Minimum acceptable approach	Stop condition
Draft copy or comments	Concise guidance plus spot review	Repeated harmless style drift
Internal prototype	Inventory, targeted checks, no production credentials	Any unexpected external side effect
Code merge	Versioned project rules, deterministic checks, protected branch	Critical rule lacks evidence
Database migration	Paired rollback, staging rehearsal, human approval	Destructive or irreversible unknown
Customer-data agent	Server authorization, tenant checks, trace and appeal	Identity or scope cannot be verified
Regulated or safety-critical workflow	Domain expert process and independent validation	Model instruction is sole control

This framework cannot establish that a model is generally compliant. It does not prove that a vendor's hidden system prompt stayed unchanged, that every tool description is honest, or that a model will behave the same after an update. It also cannot turn a prose policy into a complete security boundary.

The NIST Generative AI Profile recommends defined human-AI roles, independent assessment where risk warrants it, documented measurement, and lifecycle oversight. For a small team, that does not require a governance department. It requires a named owner, a versioned test pack, a way to stop release, and an escalation path when evidence is missing.

A 48-hour plan for a small product team

Day one: discover and classify. Choose one workflow that can change code, data, money, access, or a public deployment. Capture the compiled context if the product exposes it. Search the repository for agent instruction files, skills, hooks, tool configurations, and local overrides. List the owners and hashes. Mark each rule as guidance, checked requirement, or hard boundary. Remove stale duplicates and resolve obvious conflicts.

Then choose five critical rules. At least two should oppose the easiest default behavior. Write the expected evidence for each and identify which rules can be enforced without a model. Do not start by rewriting every prompt.

Day two: challenge and bind. Build the 12-case conflict-and-omission pack. Run it against the exact model and builder configuration you plan to use. Add deterministic checks and permission boundaries first. Re-run only after binding results to the repository commit and instruction versions. Store the instruction contract beside the release evidence.

End with one of four decisions:

Approve: critical boundaries are enforced, required evidence exists, and the conflict pack passes.
Advisory only: the agent may propose changes, but a human executes or approves them.
Narrow scope: remove production access, risky tools, or unsupported paths.
Block: a critical rule depends only on prose, conflicts remain unresolved, or the active instruction stack cannot be identified.

After launch, rerun the pack when the model, app builder, system behavior, project rules, installed skill, tool server, or permission configuration changes. Add every confirmed instruction failure as a regression case. A prompt edit without a preserved failing case erases the evidence you need.

The founder's final instruction-surface check

Before an agent can merge, deploy, send, charge, delete, or change customer state, ask:

Can we list every instruction surface that influences this workflow?
Is each source tied to an owner, scope, and version or hash?
Do we know the provider's declared role hierarchy?
Have conflicting project, skill, tool, and user rules been resolved explicitly?
Are tool descriptions treated as metadata rather than permission grants?
Are non-negotiable boundaries enforced outside natural language?
Does each required action leave independently checkable evidence?
Have we tested rules that oppose the agent's default behavior?
Does the test pack include omission as well as overreach?
Is the release bound to the tested commit, model, harness, rules, skills, and tools?
Can the system abstain or stop when a source is missing or opaque?
Is there a named person who can block release and own recovery?

If several answers are no, adding another paragraph to AGENTS.md is unlikely to fix the system. The durable rule is: instructions guide the agent; permissions constrain it; verifiers decide what evidence is acceptable.

References