Which agent changes need a deployment, and which do not | Agentic ERP Quickstart
Can the finance team change a procedure without an engineering release? Sometimes. The boundary is real, and narrower than the phrase expertise as data suggests.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 16Which agent changes need a deployment, and which do not | Agentic ERP Quickstart This article
Which agent changes need a deployment, and which do not | Agentic ERP Quickstart
Somebody in every architecture review asks the same question: can the finance team change a procedure without waiting on an engineering release? The honest answer is sometimes, and the value is in that word. Domain behavior and business procedure change at different speeds, which is why they ship on separate tracks here. The boundary between them is real, it is narrower than the phrase "expertise as data" makes it sound, and overselling it to a process owner is a promise somebody else has to break.
Series: Building governed ERP agents on AWS · Series guide →
This post: Why domain behavior and business procedures ship on different tracks, and exactly where that boundary sits.
Prereq: None. The agentic SOP model and the SOP authoring walkthrough cover the procedure model this post explains the architecture behind, if you want them first.
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. Six 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 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.
- AP is accounts payable, the example domain used below.
- Routing means selecting a procedure by configuration. Similarity search, or vector search, finds text by meaning rather than by exact match.
- AgentCore Gateway is the component that connects the agent to its tools.
Two things that change at different speeds
ERP procedures move on a different clock from domain expertise.
A finance team may revise an approval condition, an escalation path, or a quarter-end rule several times a year. Meanwhile the AP domain itself, the tools that domain may use, and its authorization boundaries stay put.
Put both in one prompt or one code artifact and you get a choice nobody wants. Either procedure owners queue behind an application deployment, or builders copy domain context into every procedure and then try to keep the copies in agreement. The second option fails quietly, which makes it worse.
The three responsibilities in one prompt
A single agent prompt is convenient at the start. Over time it accumulates three jobs that belong to different people:
| Responsibility | Who owns it | How often it changes |
|---|---|---|
| Domain instructions: how a finance process should be interpreted | Builders | Slowly |
| Routing configuration: which process type uses which procedure, and which tools are permitted | Builders, with security review | Slowly |
| The case procedure itself | Process owners | With business policy |
Going all the way to the other extreme has its own weakness. A retrieval-only design, where the agent searches for whatever looks relevant, is genuinely useful for discovery and supplementary knowledge. It is the wrong mechanism for a case you have already classified, because similarity ranking is not the same as the procedure someone approved for that route.
How the two layers fit together
The reference architecture splits the responsibilities in two. A packaged skill supplies the domain instructions, the process-type to SOP mapping, the model tier, and the Gateway tools available to that domain. The SOP supplies the case procedure.
At runtime the skill router discovers every
skills/*/config.json, indexes the configured process types, reads the selected base prompt, adds the shared platform mechanics, and fetches the mapped SOP before assembling the system prompt.Two properties are worth stating precisely. The primary procedure path injects the whole SOP, selected by explicit configuration rather than by similarity ranking. And semantic knowledge-base search stays supplementary: it is not the routing mechanism.
That split makes the scope of domain behavior visible to a reviewer, and it lets process owners govern the business procedure on their own schedule. How the agent loads its procedure covers what happens to the procedure once it reaches the agent.
Which changes need a deployment
Here is the part to get right before you promise anything.
| The change | The release path |
|---|---|
| Edit the content of an SOP that is already mapped | Publish through the SOP-only synchronization path, separately from the packaged agent code |
| Add a new skill | Packaged configuration change: validate and deploy the updated skill package |
| Change a process-type mapping | Packaged configuration change: validate and deploy |
| Change the permitted tool list | Packaged configuration change: validate and deploy, with security review |
| Add a whole new SAP domain end to end | All of the above, plus poller, schema, generated-type, and frontend work |
IMPORTANT
The benefit here is not that every new capability becomes one line of configuration. It is that procedure content can move independently once the routed capability already exists. Those are different promises, and only the second one holds.
Adding a new exception type walks through the deployment path in detail.
Make loading behavior explicit
The router recognizes text, Markdown, and PDF candidate SOP locations. PDF support depends on extracting usable text from the file, so do not treat it as a guaranteed format contract.
When a procedure cannot be loaded, the surrounding behavior is what matters. Routed execution exposes that state instead of quietly presenting itself as having loaded a procedure successfully. That visibility is the feature.
The knowledge-base tool also keeps focused SOP loading separate from semantic search. A reviewer can then tell the difference between the agent operating from the selected procedure and the agent using a broader retrieval result.
Three limits on whole-SOP injection
- Size. The content has to fit the model and embedding constraints you selected.
- Chunking. The architecture uses whole-document SOP ingestion by default and treats chunking as a corpus-specific configuration decision. That is a default, not a universal page limit.
- Document understanding. None of this implies general multimodal comprehension of a document. A diagram-heavy procedure is not handled by extracting its text.
Trade-offs
- Two artifacts to govern. The packaged skill configuration and the SOP content both need an owner, and they should not be the same person by accident.
- Two verification paths. Content synchronization and deployed routing changes need separate validation.
- Not every procedure belongs in a prompt. Large, poorly extracted, or diagram-heavy procedures need deliberate document and retrieval design, not an assumed fallback.
One caution beyond the architecture itself: this design does not prove that Amazon S3 versioning, lifecycle retention, or publisher-role controls are configured the way you expect. Verify the deployed storage controls in your own environment before making a governance claim about them.
The distinction that matters
Keep stable domain instructions, routing, and tool scope in a package that builders review. Keep fast-changing procedure content where process owners can govern it. Then be explicit about which release path each change takes.
The line is not between code and documents. It is between what should change slowly and what has to change with the business.
Where to go next
- What is an agentic SOP? The procedure model this architecture supports.
- How an agent loads its procedure . The three runtime paths and what each one substitutes.
- Adding a new exception type . The deployment path for a mapping change.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 16Which agent changes need a deployment, and which do not | 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