One of the three reasons I chose AWS Bedrock Agents over LangChain was this: a senior network support engineer can edit how an MRP diagnosis agent reasons about failure scenarios without opening a pull request. The people who understand OT network failure patterns best are not software developers. Making the iteration surface accessible to them was an architectural requirement, not a convenience.
That claim appears in the original AI-native post. Cycle 002 confirmed the marker held after a month of production scrutiny. This post is the mechanism: what is actually editable, who edits it, what the workflow looks like, and where the architecture still has a gap.
What Bedrock Agents externalises — and what it does not#
A Bedrock Agent has three components a domain expert can modify without touching the codebase:
The system prompt (instruction set). This is the agent’s reasoning frame: how it interprets a diagnostic question, what protocol knowledge it applies, how it handles data gaps. For the VLAN Agent, the instruction set encodes IEEE 802.1Q reasoning — how to interpret VLAN membership lists, what port isolation means, how to read broadcast domain configurations. A network specialist who has spent years diagnosing VLAN misconfigurations can refine this directly in the Bedrock console. No code change, no pull request, no deployment pipeline.
Knowledge base configuration. Each agent has a Bedrock Knowledge Base — documentation, standard references, known failure patterns. A domain expert can update the retrieval sources, adjust chunking strategy, and tune the relevance-score filter that governs which retrieved chunks are used.
Tool descriptions. The descriptions that tell the agent when and why to invoke each Lambda function are also editable without code changes. A network engineer who finds that the agent is invoking the wrong diagnostic tool for a class of failure can correct the description to sharpen the routing.
What domain experts cannot change without engineering involvement: the Lambda functions themselves (the actual data queries and graph traversal code), the Action Group structure (which tools exist and what their schemas are), and the Bedrock Guardrail configuration. The code layer and the instruction layer are deliberately separated.
Why this separation matters for OT diagnostics#
In OT network management, the people with the deepest domain knowledge are not engineers. Mustafa El Chariff at the Neckarthenslingen CIC has been diagnosing VLAN and MRP faults in production networks for years. He knows failure signatures that are not in any standard documentation. When the MRP Agent produces an incorrect recommendation for a ring fault scenario he has seen before, he can fix the agent’s reasoning directly — not by filing a ticket, not by waiting for a development sprint.
The alternative — domain expert describes what is wrong, engineer translates it into a prompt change, change goes through review and deployment — takes days and introduces translation loss. Bedrock’s managed instruction surface removes that intermediary for the instruction layer. The translation loss at the Lambda layer still exists and is intentional: deterministic code for data queries should not be edited without engineering oversight. But the reasoning frame belongs to the domain expert.
Network specialists own the diagnostic reasoning. Engineers own the data access patterns. The tool boundary between Lambda functions and agent instructions is where those two domains meet.
The audit gap: CloudTrail knows what changed, not how it changed#
This is the part the original marker description omitted.
When a domain expert edits agent instructions in the Bedrock console, CloudTrail records the UpdateAgent API call — the identity, the timestamp, and the request. What it does not give you is a diff: a built-in, version-controlled comparison of the instruction text before and after the change. Reconstructing what changed means pulling CloudTrail events yourself and comparing them by hand — there is no native versioning UI for agent instructions the way there is for, say, Lambda function versions.
Bedrock requires deliberate version management on top. In Digital Coworker, we handled this through ADR-tracked prompt versioning: instruction changes are documented before they are applied, reviewed at the same decision-log level as Lambda code changes, and version-controlled externally alongside the code. The Bedrock console is the execution surface; the version control is elsewhere. Accessibility for domain experts and native version diffing are in tension. Bedrock prioritised the former. The team adds the latter operationally.
What changes when non-engineers own production behaviour#
The conventional mental model of production AI behaviour is: engineers write the code, engineers own the behaviour. That model breaks as soon as the instruction layer is accessible to non-engineers.
In industrial control systems, the people who configure PLC logic are not the same people who designed the hardware — and that is deliberate. The OT engineer who knows the production line owns the configuration. The question is how you govern it.
In Digital Coworker, the governance answer is: instruction changes are treated the same way as configuration changes in the data pipeline — documented, logged, and anchored to a diagnostic reason. An instruction change without a corresponding decision-log entry is flagged. The domain expert who makes the change owns the rationale; the architecture team reviews changes that affect reasoning patterns at the protocol level (IEC 62439-2, IEEE 802.1Q). Changes that affect phrasing or escalation logic are at the domain expert’s discretion.
This is a lightweight governance model for an alpha product. It will need to evolve as write capability is added. The discipline of reasoning about what should be governed — and at what level — applies equally to instruction changes as to network configurations.
The practical implication for teams building similar systems#
The deciding question is not which framework has more features. It is: who will own the production behaviour of this system at steady state? If domain experts with protocol knowledge need to iterate the agent’s reasoning in production, the architecture has to accommodate that from the start — retrofitting an accessible iteration surface into a codebase-coupled prompt system requires deliberate work. Bedrock externalises this by design. The accepted trade-off is vendor lock-in to AWS — worth naming explicitly rather than discovering when it becomes relevant.
A note on timing: AWS announced on 2026-06-30 that Amazon Bedrock Agents — now “Bedrock Agents Classic” — enters maintenance mode for new customers as of 2026-07-30. Digital Coworker’s production system is unaffected: only CreateAgent and InvokeInlineAgent are restricted, and only for accounts with no prior Bedrock Agents usage. Everything this post describes continues to work exactly as written. But a team starting fresh today should read this as an architecture-pattern case study, not a procurement recommendation — AWS is steering new agent development toward Bedrock AgentCore, which offers a comparable declarative harness (model, tools, instructions) plus a code-defined path for full multi-agent collaboration. The governance question this post raises — who owns the instruction layer, and how you audit changes to it — is the part that generalises regardless of which AWS agent platform you build on.
The governance question this architecture creates — when non-engineers own production behaviour, who reviews what — is addressed on javatask.systems: When Non-Engineers Own Production Behaviour.
The three-agent decomposition that created the per-agent instruction surfaces is covered in: Three Specialised Agents Beat One Generalist for OT Diagnostics.
Cycle 002 covered the original AI-native marker 2 claim and its one-month qualification: The Four Markers of AI-Native: What Held Up at One Month.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.