How to Write Agent SOPs That Give AI Agents Space to Think

Agent SOPs give AI agents structured instructions while preserving their ability to reason. They are natural-language documents that tell the agent how to operate, what decisions it can make, and where to escalate. AI agents built on Amazon Bedrock AgentCore can automate complex enterprise processes, but they are only as effective as the instructions you give them.

Agent SOPs use RFC 2119  keywords (MUST, SHOULD, MAY) to give precise behavioral control without rigid scripting. They accept parameters, are readable by both humans and LLMs, and produce consistent results across runs. To learn more about the concept, see Introducing Strands Agent SOPs . See how Rivian accelerated their financial close cycle  using SOP-driven agents on Amazon Bedrock AgentCore. We use Accounts Payable exception scenarios as the example throughout this post, but the pattern applies to any enterprise process that requires contextual judgment.

You cannot anticipate every scenario an agent will encounter. A good SOP does not try to. If you could anticipate every scenario, you would not need an agent in the first place. The SOP defines what the agent must do, what it must not do, and leaves space for the agent to reason through everything else, within the boundaries.

Consider this: a vendor emails asking "Can you confirm what currency my invoice was submitted in?" The SOP never mentions this question. In a traditional system, this falls into the catch-all "else" condition and waits in a queue for a human. An agent handles it immediately. The invoice data is already available, the question is read-only, and it serves a legitimate stakeholder. The agent responds with the answer.

When a supplier sends a credit memo formatted differently from anything you have seen before. When a buyer responds to an approval request with "yes but only for the first three line items." These are the situations where if-else logic breaks and agents earn their value. The SOP is how you give them space to think, within boundaries.

When you configure an agent, you give it tools (what it can call) and boundaries (what it cannot do). Within those boundaries, the agent reasons freely to accomplish its goal. An SOP applies this same principle to business processes: it defines the boundaries of the workflow, and within them, the agent operates with full professional judgment.

A well-designed SOP has two distinct zones:

Locked (deterministic, no discretion). These are steps the agent follows exactly as written. Variance calculation formulas, approval thresholds, write sequences, and prohibited actions all belong here. The agent has zero latitude.

Open (autonomous, within boundaries). These are areas where the agent reasons like a skilled human professional. It can answer questions, provide context, suggest corrections, and communicate with stakeholders. The key constraint: any autonomous action must be read-only, must use only available data, must not contradict any locked rule, and must serve a legitimate stakeholder interest.

The locked sections are the boundaries. The open sections are where the agent thinks.

Without the open zone, the agent adds no value beyond what code can deliver. Without the locked zone, the agent produces inconsistent, non-compliant results . The how-to section below shows what both zones look like as actual SOP text.

An Agent SOP is composed of the following sections. The excerpts shown are illustrative, not a comprehensive accounts payable implementation.

Open your SOP with the keywords you will use to control behavior. RFC 2119 keywords (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY) give you precise behavioral control because large language models are trained on documents that use this standard. Add severity markers for critical situations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.

Additionally, the following severity markers are used:

  CRITICAL:  Violation will cause data corruption, financial loss, or
             compliance failure. The agent MUST halt and escalate.

  NEVER:     Action is absolutely prohibited under all circumstances.
             No exception, no override, no workaround.

State three things clearly: what the agent is, what the goal is, and what the goal is not. This section sets the agent's mental model. When the agent encounters an ambiguous situation not explicitly covered by later sections, it refers back to this framing to guide its decision.

The agent's role is to act as a diligent accounts payable analyst: gather
facts, classify the problem, apply the correct resolution, and escalate
when human judgment is needed.

The goal is NOT to auto-approve everything. The goal is to resolve what can
be resolved safely and escalate what cannot. Quickly, accurately, and with
a complete audit trail.

Scope and Authority

Explicitly declare what the agent can and cannot do. Do not assume anything is obvious. If you do not explicitly prohibit creating a goods receipt, an agent might attempt it because the action seems logical in context.

List permitted actions. List prohibited actions. Be specific.

The agent MUST NOT process invoice types not covered by this SOP.
The agent MUST NOT approve, post, or release any payment without
  satisfying every applicable condition defined herein.
The agent MUST NOT modify PO data, goods receipt data, or master data.
  The agent's authority is LIMITED to invoice processing actions only.

CRITICAL: The agent MUST NOT create, modify, or delete any financial
document outside the scope of the current case. Each case is isolated.

NEVER: The agent MUST NEVER bypass approval workflows, even if the
variance is small or the approver is unavailable.

Define all valid states a case can be in (new, in_processing, on_hold, pending_vendor, escalated, complete, error) and the valid transitions between them. Define terminal states where no further transitions are permitted.

This gives the agent a map of where it is and where it can go. Without explicit state management, agents sometimes re-process completed work, skip steps, or transition to invalid states.

Include a concurrency lock: "Before starting work, the agent MUST set status to in_processing. If already in_processing, another agent is working it. Back off."

After defining states and before writing the procedural steps, explicitly declare what is locked and what is open. This is where you draw the line between "follow exactly" and "reason freely."

The following areas are governed by explicit rules. The agent MUST follow
them exactly as written, with no interpretation or deviation:

Exception classification priority order

Variance calculation formulas

Tolerance threshold application

SAP write sequence: park → poll → (release if blocked) → post → poll

Halt conditions

All items in the Prohibited Actions list

The agent MAY use its judgment and initiative for any action that satisfies
ALL of the following conditions:

  It is READ-ONLY. no SAP writes, no financial document changes,
     no master data modifications.
  It uses ONLY data already retrieved in Step 1 or data available
     through read-only SAP queries.
  It does NOT contradict any MUST, MUST NOT, CRITICAL, or NEVER
     statement in this SOP.
  It serves the legitimate interests of a stakeholder in the process.

  A vendor asks "When will I get paid?"
    The agent SHOULD look up payment terms from the PO, calculate the
    expected payment date, and respond with a helpful, accurate answer.

  After resolving an exception, the agent SHOULD proactively notify
    the vendor of the outcome, even if the resolution path does not
    explicitly list a vendor notification.

  Adjusting a tolerance because the variance "seems reasonable"
    NEVER. Tolerances are configuration, not judgment calls.

  Posting an invoice because the vendor "urgently needs payment"
    NEVER. Urgency does not override the SOP steps.

  Creating a goods receipt because "the goods are there"
    NEVER. Only warehouse personnel post GRs.

This section is what gives the agent space to think. Without it, you have a rigid script. With it, the agent can handle the vendor currency question from our earlier example because the boundaries are explicit and the open zone is clearly defined.

Write ordered steps with clear entry and exit criteria. Each step has its own constraints. Use natural language for conditional branching: "IF above tolerance AND over-delivery, escalate to buyer. Set status to pending_buyer."

Natural language branching is more resilient than code because the agent can interpret intent even when a vendor phrases their response in ways you did not anticipate.

QUANTITY VARIANCE RESOLUTION

  IF variance is WITHIN tolerance:
        The agent MUST auto-accept the invoice.
        Log: "Quantity variance within tolerance."

  IF variance EXCEEDS tolerance
        The agent MUST escalate to buyer for approval.
        Set status to pending_buyer. STOP.

Maintain an explicit "NEVER" list at the end of your SOP. Even if a prohibition seems obvious, state it explicitly. Being clear about boundaries removes ambiguity and strengthens compliance:

NEVER post a goods receipt (only warehouse personnel do this)

NEVER bypass approval workflows, even if the approver is unavailable

NEVER fabricate or estimate data values not retrieved from the source system

Separate configuration from logic. Tolerance thresholds, formulas, notification templates, and contact lists belong in reference sections. When business requirements change, teams update only the reference section. The procedural steps, the agent code, and the deployment do not need to change.

TOLERANCE THRESHOLDS (CONFIGURABLE)

  Quantity tolerance:
    Percentage: ±5%
    Absolute:   ±10 units
    Rule: Whichever threshold is GREATER applies.

  Price tolerance:
    Percentage: ±2%
    Absolute:   ±$0.50/unit
    Rule: Whichever threshold is GREATER applies.

  Amount tolerance:
    Absolute:   ±$100 per line item

If a finance manager decides the price tolerance should be ±3% instead of ±2%, they update this section. The steps that reference "tolerance" continue to work unchanged because they point to these values rather than hardcoding them.

 

An SOP is one layer in a broader architecture that shapes agent behavior:

·       Agent persona sets the role and professional identity ("You are an Accounts Payable specialist responsible for resolving invoice exceptions. You are thorough, compliance-aware, and prioritize accuracy over speed."). This gives the LLM context for how to reason and communicate.

·       The SOP defines operational boundaries, locked procedures, and open space for judgment. This is the layer we focus on in this post.

·       Amazon Bedrock Guardrails  filter harmful, off-topic, or sensitive content at the model level.

·       Cedar policies  enforce fine-grained authorization: which actions the agent can take, on which data, for which users.

·       IAM policies  control which AWS resources and APIs the agent can access.

·       Downstream API authorization. The target system (e.g., SAP) enforces its own access controls on the authenticated service account, independent of the agent's AWS-layer permissions.

These layers complement each other. This post focuses on the SOP layer: what steps to follow, where to exercise judgment, and when to escalate.

An SOP lives in an Amazon Bedrock Knowledge Base. The agent retrieves it via RAG at runtime based on the exception type it is handling. This means the SOP controls agent behavior at runtime. An unauthorized or untested SOP change is equivalent to an untested code deployment. Apply the same rigor you apply to release management.

Amazon Bedrock AgentCore memory  adds a dynamic learning layer on top of the static SOP. As the agent processes cases, it accumulates operational context: vendor-specific patterns, resolution outcomes, and escalation history. This memory helps the agent make better decisions within the open zone without requiring an SOP update for every new pattern it encounters. It also surfaces insights that inform the next SOP revision. For example, if the agent observes that a specific vendor category escalates 80% of the time, that signal can prompt the process owner to adjust thresholds or add a category-specific branch in the next version.

When Memory surfaces a pattern that requires a structural SOP change, apply the improvement loop:

·       Review agent decisions at approval checkpoints

·       Identify cases where the agent escalated unnecessarily (SOP too rigid) or took incorrect action (SOP too loose)

·       Update the SOP to address the gap

·       Release the new version through your managed pipeline

Use semantic versioning (v1.0, v1.1, v2.0) with a revision history that records who changed what, when, and why. Store SOPs in an Amazon S3 bucket with strict IAM policies. Only authorized roles (process owners, compliance leads) can write to the bucket. Enable S3 versioning for rollback capability and access logging with AWS CloudTrail for a complete audit trail.

Updating an SOP is a deployment, not a file edit. The process:

·       Draft the change (author)

·       Review and approve (process owner + compliance)

·       Upload to S3 (authorized role only)

·       Refresh the development Knowledge Base and validate agent behavior using Amazon Bedrock AgentCore Evaluations 

·       Promote to higher environments (staging, live) once testing confirms no regression

The Knowledge Base refresh is the deployment step. Until you sync a given environment, the agent in that environment continues using the previous version. This gives you a controlled promotion path: verify in development, then roll forward with confidence.

Once your SOP is written, you need a robust framework to deploy it. AWS Agentic Standard Operating Procedures (SOPs) for ERP Automation  covers the full architecture and technical best practices for running SOP-driven agents against SAP environments, including determinism controls, identity propagation, progressive trust models, and audit trail design.

To get started:

·       Identify a process where contextual judgment is needed.

·       Review the sample SOP (PDF)  to see a fully written example of the patterns described in this post.

·       Write your SOP with the locked and open zones clearly defined, following the section-by-section guidance in this post.

·       Store it in S3 with tight access controls and version it as managed infrastructure.

·       Deploy using the open source reference implementation: sample-agentic-ai-process-automation-for-sap . This repository provides a complete, deployable agent built on Amazon Bedrock AgentCore with SOP-driven intelligence.

·       Start in advisory mode, build trust progressively, and expand autonomy as confidence grows.

Then let the agent do what agents do best: think like a skilled professional, within the boundaries you set.