An MRP (Media Redundancy Protocol) failover diagnosis that previously took days now takes minutes — an improvement of two orders of magnitude. That improvement did not come from a faster algorithm or a more powerful model. It came from four architectural decisions made before the first agent was deployed — decisions that make the Digital Coworker system AI-native rather than AI-augmented.
“AI-native” is now used to describe anything that includes an LLM. Most of those claims are retroactive relabeling: an existing data model and a chatbot layer on top. A genuinely AI-native architecture is observable. Here is what it looks like.
Observable Difference 1: The Data Schema Was Designed for Agent Consumption#
The first architectural decision in Digital Coworker was moving from MySQL/ClickHouse to Apache Iceberg as the storage layer for OT (operational technology) network telemetry. This was not a performance optimization. It was a prerequisite for AI-native operation.
MySQL is a relational database optimized for transactional read/write by application code written by engineers. Apache Iceberg is an open table format designed for large-scale analytical queries, schema evolution over time, and — critically — direct consumption by systems that do not have a human in the loop managing query construction.
The difference for agent-facing data looks like this: a MySQL schema designed for application developers requires agents to know the table structure, manage joins, handle pagination, and break when the schema changes. An Iceberg table on AWS Athena offers schema evolution where adding or renaming columns does not break existing queries — Iceberg tracks columns by immutable Field IDs, not names, so logical renames are metadata-only operations. Destructive changes (dropping a referenced column, narrowing a type) remain breaking, as they are in any storage system. The data can be partitioned and sorted by the dimensions the agent actually queries — time window via days() or hours() transform, topology layer and device type as low-cardinality identity partitions, and failure class as a sort-order column whose min/max statistics enable predicate pushdown without the small-file cost of physical partitioning. ClickHouse is already columnar and analytical; the migration from ClickHouse to Iceberg is justified by different needs — open-format portability, schema evolution across multiple independent consumers, and snapshot isolation for agent time-travel queries — not by the transactional tradeoffs that constrain MySQL. These are not MySQL’s failure modes — they are MySQL’s tradeoffs for the transactional workloads it was designed for.
When we analyzed 152 customer projects representing more than 400 OT devices types to build the knowledge base that grounds our topology agent, the data pipeline required to process that corpus was practical only because the storage layer was designed for it. The same analysis against a MySQL-based system would have required a migration project before the AI work could begin.
AI-native means the data layer was designed for agent consumption from the start. Everything else follows from this.
Observable Difference 2: Non-engineers Can Iterate the Agent Instructions#
The second decision was choosing AWS Bedrock Agents over LangChain as the agent framework. The reasoning was not about capability — LangChain is a capable framework. It was about who could iterate the agent’s behavior after deployment.
LangChain can externalize prompts and configuration, but it requires deliberate architectural work — prompt templates need to be managed outside the codebase, access controls established, and a deployment pipeline wired in. AWS Bedrock Agents externalizes the agent’s reasoning instructions by design — the system prompt, the knowledge base configuration, the tool descriptions — into a managed console interface that does not require code changes to edit.
In practice, this means a senior network support engineer at Belden can refine how the MRP diagnosis agent reasons about failure scenarios directly in the Bedrock console, without opening a pull request. The people who understand OT network failure patterns best are not software engineers. They are network specialists who have spent years diagnosing these exact problems.
AI-native means the people with the deepest domain knowledge can iterate the AI’s behavior without going through engineering. The architecture makes this possible or it does not.
Observable Difference 3: Read-Only Posture at Launch Is a Feature, Not a Limitation#
The third decision was launching with read-only agent posture — no autonomous write operations. The product direction included write capability. Intent-Based Networking, where an agent can execute configuration changes directly, was on the roadmap. The architectural argument for deferring it was: OT environments are safety-critical, a validated trust model for autonomous write operations in production OT environments was not yet established, and a single hallucinated network configuration change can take a production line offline.
This argument was made before any external validation. Deferring IBN to a future release was the harder choice precisely because it constrained the product’s perceived capability at launch.
But the read-only posture is what made the system deployable in OT environments at all. Industrial automation customers with production-critical networks will not allow a system to execute write operations unless they have run it in read-only mode long enough to trust it. The launch posture was the trust-building mechanism.
AI-native means the architecture encodes a trust model, not just a capability model. Shipping with read-only posture was not a compromise — it was the correct sequence.
Why All Four Decisions Add Up: Domain Depth Over Generality#
A single general-purpose agent with broad instructions degrades quickly in specialized domains. OT network diagnostics requires knowledge of IEC 62439-2 (the MRP standard), Spanning Tree Protocol topology analysis, VLAN segmentation patterns, and the specific failure signatures of industrial switches under load. Packing all of that into one agent’s context produces worse results than building three specialized agents — one for topology, one for configuration analysis, one for failure pattern matching — each with a focused knowledge base and a clear tool surface.
This is the same principle that makes specialized human teams more effective than generalists for complex diagnostic work. The AI architecture mirrors the organizational structure that actually solves the problem.
The improvement in MRP failover diagnosis — from days to minutes — comes from all four of these decisions together. The data was designed for agent consumption. The agents can be iterated by domain experts. The system launched in a trust-appropriate posture. The agents are specialized for the domain depth the problem requires.
The organizational changes required to build and govern an AI-native product are covered on javatask.systems: From AI as Feature to AI as Product: The Org Chart Has to Change Too.
The multi-agent architecture and anti-hallucination design decisions behind graph traversal vs. RAG in OT diagnostics are covered in: Why Graph Traversal Beats RAG for Safety-Critical OT Diagnostics.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.