How an agent loads its procedure: three retrieval paths | Agentic ERP Quickstart
Routed injection, direct lookup, and vector search deliver the same document differently. What each substitutes before the model reads it, and how each fails.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 9How an agent loads its procedure: three retrieval paths | Agentic ERP Quickstart This article
How an agent loads its procedure: three retrieval paths | Agentic ERP Quickstart
The same procedure document can work perfectly on one retrieval path and quietly underperform on another, which is how a procedure that passed review still produces a wrong answer in production. Three separate mechanisms deliver procedure text to this agent: routed injection when the case type is already known, direct lookup by name, and vector search across the corpus. Each one substitutes something different before the model ever sees the text, and each one fails differently when a document is missing. Testing one of them tests neither of the others.
Series: Building governed ERP agents on AWS · Series guide →
This post: The three ways procedure text reaches the agent at runtime, and why testing one does not test the others.
Prereq: None, though the agentic SOP model explains why skills and SOPs are separate and the authoring walkthrough covers writing one.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Four terms recur below:
- An SOP is a standard operating procedure: the written steps for resolving one kind of exception. Here, the agent reads it.
- A skill is a deployed package covering one business domain. It declares the allowed tools, the known values, and which SOP maps to which case.
- A process type is the label on an incoming case. It is how the agent picks the right procedure.
- Vector search finds text by meaning rather than by exact match. It returns passages that resemble the query, along with where they came from.
What a known exception actually needs
An exception arrives carrying a process type. To work it, the agent needs more than a document that happens to look similar. It needs the right domain context, the approved procedure for that specific type, the declared policy values, and the contacts who own escalations.
Saying the agent "retrieves an SOP and follows it" hides the details that decide whether this works in production: whether the procedure was explicitly mapped or merely matched, whether the agent got the whole document or a few excerpts, what happens when the file cannot be read, and which values were substituted before the model saw the text.
Three paths, three sets of limits
| Path | Use it for | What it delivers | The limit that matters |
|---|---|---|---|
| Routed SOP injection | A known case with a configured process type | The mapped SOP, injected into the assembled skill prompt, with configured constants and contacts resolved | Depends on a valid skill mapping and a readable SOP object |
load_sop | Focused lookup by process type | The mapped SOP for that process type, with contacts and constants resolved on the supported Gateway path | The Gateway Lambda function does not parse PDF SOPs |
search_sap_sops | Discovery across the whole SOP corpus | Bedrock vector search results: matching text plus source locations | Substitutes contacts only, not skill constants. Relevance is not proof of completeness. |
Why separate paths instead of one
Vector search earns its place when the agent has to find relevant material in a larger corpus. What it returns is matching text and source locations. What it cannot promise is that the best or the complete procedure was selected. A general search also has no idea which skill's constants apply to the passage it found.
A configured route works the other way around. For a known process type, the implementation can name the exact document and load it into the prompt. The agent starts from the procedure someone approved for that route, instead of from whatever the similarity score put first.
Neither path makes the model's output deterministic, and neither proves it is correct. The SOP is an input to the model, not an execution engine. A responsible design combines clear procedures, runtime error handling, real authorization, and human review wherever the process calls for it.
How a known case is assembled
For a mapped process type,
skill_router.resolve_skill() selects the skill whose configuration owns that type. It loads that skill's base prompt, injects the shared platform mechanics, fetches the mapped SOP, and places the SOP inside the <sop_document> section of the prompt. Then it substitutes the configured constants and contacts.1
2
3
4
5
6
7
8
9
# TEACHING VERSION; stripped to the essential pattern
# Full reference: agentcore/agent/utils/skill_router.py
def resolve_for_case(process_type: str) -> PromptContext:
skill = select_skill(process_type)
prompt = inject_platform_mechanics(skill.base_prompt)
sop_text = fetch_sop(skill.sop_path_for(process_type))
prompt = prompt.replace("{SOP_CONTENT}", sop_text)
return resolve_constants_and_contacts(prompt, skill)This is the primary path for a known case, and it is not search. The important property is configuration: the process-type mapping decides which procedure to load before the model starts reasoning about the case at all.
Focused lookup and corpus search answer different questions
The
load_sop Gateway tool is a focused lookup for a named process type. It resolves the relevant SOP and applies that path's constants and contacts. Reach for it when the caller already knows which procedure it wants.search_sap_sops does something different. It uses Bedrock vector search to return matching text and source locations from across the SOP corpus. That is genuinely useful for discovery, and for questions that span several procedures. It is not a substitute for a complete configured SOP when the case already has a known route, and its results resolve contacts but not the constants a particular skill declares.Keeping that distinction visible keeps your reporting honest. A retrieved paragraph can be useful evidence. On its own it cannot show that the agent used every step of a procedure, or that the resulting action was authorized.
Failure behavior is part of the design
A missing or unreadable procedure does not produce one universal outcome. It depends on the path:
- On the routed path, a missing SOP object produces a marker in the prompt, along the lines of
[No SOP loaded for ... - operating on domain expertise only], and reportssop_loaded=False. The agent continues on domain expertise alone. Do not describe every missing SOP as a hard stop, because this one is not. - A fetch, decode, or parse failure can raise
SopLoadError. That is a real operational failure. Investigate it rather than papering over it with a generic success message. - On the discovery path, skills with no loaded SOP are simply left out of the results.
Your release process should decide which of those outcomes is acceptable for each exception type. If a procedure is mandatory for a process, validate its object, its mapping, and its parseability before you enable that route. Prompt wording alone does not turn an optional fallback into a mandatory control.
Two boundaries that will surprise you
PDF parsing is not uniform. The router can extract text from PDFs using
PyPDF2. The Gateway implementation behind load_sop does not include that parser, so PDF support differs by path. Author in text or Markdown for the most predictable behavior, or validate the specific path your workflow depends on.Substitution is not uniform either. The routed prompt resolves both constants and contacts.
load_sop resolves both on its supported path. search_sap_sops resolves contacts only. So a procedure that depends on a symbolic tolerance has to be validated in the exact path that will present it to the agent, not in whichever path is easiest to test.Trade-offs
- What you gain. A known route starts from a reviewed, explicitly mapped procedure, while vector search stays available for discovery and supporting context.
- What you give up. There are multiple runtime paths to understand and test. File format, parsing, and substitution behavior are all path-specific.
- What the design does not promise. SOP injection and retrieval do not guarantee grounding, factual accuracy, hallucination prevention, deterministic execution, or SAP authorization.
Test the paths separately
An agent does not execute a document the way a workflow engine executes code. It assembles context and reasons over it. In this implementation, the strongest procedure context for a known case is the complete, configured SOP injected through the skill route. Focused lookup and vector search are valuable alongside it, but they substitute different values and fail in different ways.
Make those differences part of your test plan and your release criteria, not something you discover in production.
Where to go next
- What is an agentic SOP? Why skills and SOPs live on separate release tracks.
- How to write an SOP an agent can follow . Authoring, constants, entity sets, and the knowledge base sync.
- Next series phase: the governance and trust posts examine topology-specific authorization and audit controls. Publish those only after the required security review.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 9How an agent loads its procedure: three retrieval paths | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article