A better prompt can improve an answer.

It cannot define an operating boundary.

That distinction matters once an AI system stops behaving like an assistant and starts behaving like an actor. The moment an agent can call tools, change state, spend money, open pull requests, alter configuration, create artifacts or trigger another agent, the organization needs something stronger than prose telling the model to be careful.

This is Part 5 of the ten-part series AI Governance in an AI-Native Software Development Company. Part 4, The Executable Policy Layer, established that governance only becomes real when policy reaches the execution path. This article moves the boundary closer to the agent itself: what exactly is the agent allowed to do, under which conditions, with which tools, and what must happen when the conditions are not satisfied?

The answer is a contract.

Prompts express intent. Contracts bind behavior.

Prompts are not a control surface

Prompts are useful because they are flexible.

That is also why they are weak as contracts.

A prompt can say:

"Review this deployment carefully. Do not make risky changes. Ask for approval when necessary."

A human can infer a lot from that sentence. An agent has to reconstruct the missing rules every time it runs.

What counts as risky?

Which environment is in scope?

Which tools may it call?

What evidence must exist before it approves?

How much can it spend?

What should it do when evidence is incomplete?

Who can authorize an exception?

What output shape must downstream systems receive?

What happens if the model, tool schema or runtime changes?

The prompt does not answer those questions. It gestures toward them.

That may be enough for a low-stakes assistant. It is not enough for a system with authority.

The runtime always wins.

Whatever the prompt intended, the real behavior is defined by the capabilities the runtime exposes and the boundaries the runtime enforces.

The contract stack

A useful way to separate the pieces is:

  • prompts express intent
  • instruction files provide context
  • skills and rules define the working contract
  • enforcement surfaces make the contract binding
  • runtime verification produces attestation
  • evidence and refusal create the record

The terms can vary between platforms. The separation should not.

A prompt may say what the agent should achieve.

A contract says what the agent may do while trying to achieve it.

That is the difference between advice and authority.

What belongs in an agent contract?

An agent contract does not need to begin as a giant governance schema.

It needs to make the hidden assumptions explicit.

A practical contract usually needs at least these dimensions.

Identity and ownership

Every deployed agent or capability needs a stable identity, version and owner.

You should be able to answer:

  • what agent is acting
  • which capability bundle is active
  • who owns the contract
  • when it was approved
  • when it expires or must be reviewed

An unnamed agent with a shared service account is already difficult to govern.

Purpose and non-goals

State what the agent exists to do and what it explicitly does not do.

"Help with deployments" is vague.

"Evaluate deployment evidence for service X and recommend allow, deny or human review; never execute production deployment" is a contract.

Non-goals matter because autonomy expands through ambiguity.

Tool and resource scope

List the tools the agent may call and the resources those tools may reach.

The contract should distinguish between:

  • read and write
  • development, staging and production
  • one repository and every repository
  • one tenant and all tenants
  • observation and mutation

A tool existing in the runtime should not automatically mean the agent is authorized to use it.

Inputs and preconditions

Define what must be true before the capability runs.

Examples include:

  • required request fields
  • required evidence
  • required policy version
  • required human delegation
  • required environment state
  • maximum age of retrieved information

If a precondition is missing, the system should know whether to refuse, defer or escalate.

Outputs and postconditions

Downstream systems should not have to guess what the agent meant.

Contracts should define:

  • output schema
  • required evidence references
  • confidence or uncertainty fields when useful
  • allowed decision states
  • expected side effects
  • conditions that must hold after execution

A natural-language paragraph can still be part of the output. The machine-relevant part should not depend on prose interpretation alone.

Risk, blast radius and budgets

A contract should state how much authority the capability can exercise.

That includes more than permissions.

Useful boundaries include:

  • maximum action class
  • maximum blast radius
  • cost budget
  • token budget
  • time or step budget
  • concurrency limit
  • rate-limit envelope

The contract is where "how far can this go?" becomes explicit.

Refusal and escalation

Refusal is not a model failure.

In a governed system, refusal can be the correct result.

The contract should define when the agent must stop, when it may degrade gracefully, when it must ask for approval and when it should quarantine an output instead of sending it into the live path.

If refusal behavior is unspecified, the agent is forced to improvise at exactly the moment the organization most needs deterministic behavior.

Evidence

Every material action should leave enough evidence to reconstruct why it happened.

The contract can require fields such as:

  • inputs consulted
  • knowledge or source references
  • tool calls
  • policy version
  • contract version
  • decision reason
  • approvals
  • exceptions
  • resulting side effects

This is where agent behavior becomes auditable rather than anecdotal.

Prompts are read. Records are signed.

A contract can be small

The first version can be deliberately simple.

For example:

~~~yaml agent_contract: id: deployment-reviewer version: 3 purpose: review deployment evidence

allowed_tools:

  • read_repository
  • read_ci_results
  • read_runtime_health

forbidden_actions:

  • deploy_production
  • modify_secrets

preconditions:

  • deployment_evidence_present
  • active_policy_version_present

outputs: schema: deployment_review_v2 allowed_decisions:

  • allow
  • deny
  • require_approval

escalation: when:

  • evidence_incomplete
  • blast_radius_above_medium

evidence: required:

  • sources_used
  • policy_version
  • contract_version
  • decision_reason

~~~

The syntax is not the point.

The important shift is that assumptions are now visible, testable and versionable.

A team can review this artifact.

A pipeline can validate it.

A runtime can enforce parts of it.

An evaluator can test behavior against it.

An incident reviewer can ask which version was active.

That is already much stronger than "be careful."

Skills are not contracts by themselves

Modern agent platforms increasingly package capabilities as skills, rules, instruction files, manifests or tool bundles.

That is useful progress.

But a skill describing how to perform a task is not automatically a governance contract.

A skill may explain how to deploy a service.

The contract still has to answer:

  • may this agent deploy this service
  • to which environment
  • under whose delegation
  • with what evidence
  • inside what blast radius
  • with what budget
  • using which version of the skill
  • with what rollback or containment requirement

The same skill may be safe for one agent and unsafe for another.

The same tool may be acceptable in staging and prohibited in production.

The same intent may be allowed at 10:00 and require approval during an incident.

Capability and authority are different things.

A useful rule is:

A skill tells the agent how. A contract tells the system whether, where and under what conditions.

Contracts have to survive runtime drift

Even a good contract becomes meaningless if the behavior surface changes underneath it without control.

Agent behavior can move when any of these change:

  • model
  • system prompt
  • instruction file
  • skill
  • tool schema
  • permission
  • routing rule
  • retrieval source
  • policy bundle
  • runtime host

That means the contract has to bind to versions, not names that silently drift.

"Use the coding agent" is not enough.

"Use capability bundle 4.7 under contract 3.2 and policy bundle 12" is governable.

The contract does not have to freeze the system forever.

It creates a point where change becomes visible.

When a model or skill upgrade alters behavior, the capability bundle changes. The contract can be re-evaluated, re-tested and re-approved.

Without that discipline, a contract becomes documentation about a system that no longer exists.

Runtime verification is the missing half

Writing the contract is not enough.

A system needs to verify that execution stayed inside it.

That verification can include deterministic checks such as:

  • only allowed tools were called
  • forbidden resources were untouched
  • required evidence was present
  • budget limits were respected
  • output matched the required schema
  • escalation happened when a threshold was crossed

It can also include behavioral evaluation where deterministic checks are not enough.

The key is that the result should become an attestation tied to the execution trace.

The useful question is not only:

"Did the agent finish?"

It is:

"Did the agent finish inside the contract?"

That is a much stronger definition of success.

Refusal is part of the product

Agent teams often optimize heavily for completion rate.

That creates pressure to treat refusals and escalations as failures.

Governance needs a different view.

A well-designed agent should refuse when:

  • required evidence is missing
  • requested authority exceeds its scope
  • the caller lacks delegation
  • the action would cross its blast-radius boundary
  • budget is exhausted
  • policy state is ambiguous
  • the runtime cannot prove that a required control is active

A refusal with a structured reason is not dead output.

It is a governed outcome.

The same applies to "require approval," "defer" and "quarantine."

When those outcomes are explicitly represented in the contract, the system can route them instead of forcing the model to invent recovery behavior.

The contract should be testable

If a contract cannot produce tests, it is probably still too vague.

For each important clause, ask what evidence would prove compliance.

If the contract says the agent cannot deploy to production, write a test that offers the deployment tool and verifies that the runtime blocks it.

If the contract requires escalation above a blast-radius threshold, test the boundary.

If the output must include evidence references, reject outputs that omit them.

If a budget must stop the workflow, drive the agent to the limit in a non-production environment and observe the result.

The contract becomes valuable when it is connected to evaluation.

Otherwise it is another document waiting to drift.

Practical build order

Do not begin by designing an enterprise-wide agent contract language.

Start with one real capability.

1. Pick an agent that can cause a side effect

Read-only assistants are useful, but they hide the hard governance questions.

Choose one capability that can change state, spend money, open a PR, modify configuration or trigger deployment.

2. Write the smallest explicit contract

Define identity, purpose, non-goals, tools, resources, preconditions, outputs, risk boundary, refusal, escalation and evidence.

Keep it small enough that the owning team can actually review it.

3. Bind the contract to versions

Pin the model, prompt, skills, tools, policy bundle and host assumptions that materially affect behavior.

Treat a change to those elements as a capability change.

4. Enforce the hard boundaries outside the model

Do not ask the model to police its own highest-risk permissions.

The runtime should block actions that exceed the contract.

5. Emit contract evidence

Attach the contract version and the important compliance signals to the same trace as the action.

Make the execution reconstructable.

6. Test refusal and escalation

Do not evaluate only the happy path.

Force missing evidence, exceeded scope, budget pressure and ambiguous policy state.

Confirm that the system fails the way the contract says it should.

7. Review contracts as operational artifacts

Contracts should have owners, versions, review dates and a retirement path.

They belong in the production lifecycle.

Closing

The prompt is not going away.

It is simply being put in the right place.

Prompts are excellent for expressing goals, context, tone, strategy and flexible reasoning.

They are poor substitutes for authority boundaries.

An AI-native organization needs both.

The prompt tells the agent what the human wants.

The contract tells the system what the agent is allowed to do while pursuing it.

The enforcement layer makes that contract real.

The runtime evidence proves whether the contract was respected.

And refusal gives the system a legitimate way to stop when the contract cannot be satisfied.

That is the progression:

intent -> contract -> enforcement -> attestation -> evidence.

The contract is becoming an executable behavioral specification between humans, agents and tools.

Not because agents need more paperwork.

Because autonomy without a contract is simply unbounded interpretation with access to tools.

The next article assumes something uncomfortable: the agent will sometimes operate outside the contract anyway.

That is where containment begins.

Next in the series: AI Governance Fails Without Containment.

Originally published by Reza Arani on Medium on May 29, 2026. Adapted for Aipolix as Part 5 of the AI Governance in an AI-Native Software Development Company series.