DEV Community: Reno Rajan Christy

Built to Last — and to Extend

Reno Rajan Christy — Sat, 31 Oct 2026 07:31:55 +0000

As AI systems take on more autonomous decision-making with less continuous human review, the cost of an incomplete design rises sharply: a missed edge case is no longer caught by a human in the loop before it causes harm, it is executed. This piece argues that design thinking in the AI era needs a structural discipline borrowed, deliberately, from how buildings get engineered — a practice of separating the requirements that are load-bearing from the requirements that are finish-work, and ensuring the former are never skipped even when time or budget forces the latter to be deferred. It develops a Structural-Priority Framework for requirements coverage, resting on a single diagnostic — the silence test — alongside practical treatments of systems thinking, edge-scenario anticipation, redundancy, proactive resilience, longevity, and extendability as strategic positioning. It closes with a reference grid applying the framework to data and AI decision solutioning, and argues that vision, role clarity, and cultural cohesion are themselves foundation-tier requirements of the delivery system — a diagnosis DSDM anticipated and that most agile adoptions discard.

1. Introduction: Why Design Thinking Needs a Structural Discipline Now

Design thinking, as a discipline, is built around empathy for the user and rapid iteration toward a working solution. Both are still necessary. Neither is sufficient once a meaningful share of a system’s decisions are made by an AI component rather than reviewed, in real time, by a person. A flawed interface can be fixed after a user complains. A flawed decision boundary inside an autonomous system can execute thousands of times, at machine speed, before anyone notices the pattern. The U.S. National Institute of Standards and Technology’s Artificial Intelligence Risk Management Framework (NIST AI 100–1, 2023) exists precisely because this shift — from AI as a decision-support tool to AI as a decision-making component — changes what “good design” has to guarantee, not just what it should aspire to.

A flawed interface can be fixed after a user complains. A flawed decision boundary inside an autonomous system can execute thousands of times, at machine speed, before anyone notices the pattern.

This is a practitioner’s attempt to make that guarantee concrete. It draws on more than a decade of building high-availability, regulated financial systems, and on the design of edge-resident AI architectures where failure handling has to be specified in advance rather than discovered in production.

2. Systems Thinking, Problem Solving, and Critical Thinking as Engineering Disciplines

Systems thinking is the discipline of seeing the system of systems — the complex ecosystem of dependencies, feedback loops, and second-order effects that a component-level view misses. Critical thinking is the companion discipline of actively probing the first plausible design rather than accepting it. Problem solving is what the two produce in practice: tracing a fault to the layer of the system where it actually originates, rather than patching the symptom closest to where it was noticed, so the same failure does not resurface in a different guise three releases later. None of the three is a soft skill in complex ecosystem environments; all three are load-bearing.

In regulated financial environments — where IT risk assurance, regulatory reporting, and central-bank supervisory programs intersect — no single stakeholder’s requirement can be evaluated in isolation. A change made to satisfy an examiner still has to reconcile against every ancillary application bolted onto a core transaction system, each with an independent owner and its own definition of correct. The same constraint governs the design of backend infrastructure for a real-time platform serving an entire institution: every design decision has to be evaluated against dependencies that are, by definition, invisible from inside any single team’s backlog. Systems thinking, in both cases, is not a planning exercise performed once at the start of a project. It is a standing discipline of asking what else does this touch, every time a change is proposed.

Physical-AI and edge-AI systems push that discipline further. An architecture spanning sensor-level intelligence, on-device fusion and inference at an edge tier, and a cloud layer for fleet-wide analytics has to be reasoned about as one interdependent system across embedded firmware, edge AI, and cloud data engineering — because a design flaw at the sensor layer can silently corrupt a decision three layers away if it is not anticipated up front.

3. Seeing the Break Before It Happens: Anticipating Edge and Weak Scenarios

Most designs are tested against the scenario they were built for. Fewer are tested against the scenario in which one of the design’s own components has already failed. That second category — not “what happens under normal load” but “what happens when the thing meant to detect the problem is itself the problem” — is where the most damaging edge cases live.

Monitoring systems make the point sharply. The obvious requirement is to detect when the monitored process goes wrong. The harder and more consequential requirement is to detect when the instrument goes wrong: to recognize that a sensor is degrading, and to distinguish that degradation from a genuine event in the process being watched. A system that cannot tell those apart does not fail loudly. It fails by producing confident, well-formatted, wrong output — which is considerably worse, because nothing in its behavior invites anyone to check it.

The weak scenario worth designing against is not “the machine breaks,” it is “the thing watching the machine breaks, and the system must not mistake that for either a healthy asset or a failing one.”

The same discipline appears in high-availability transaction processing. A real-time authentication path that integrates mainframe transaction systems, message-queue middleware, and relational back ends, deployed through CI/CD in a containerized environment, is not made highly available by adding redundancy once the primary path works. High availability is a property that exists only if every failure mode of every integrated component — the message queue as much as the mainframe — has been anticipated in advance and given an explicit fallback, including the failure modes of the components whose job was to notice failures.

4. Strength, Redundancy, and Optimum Solutioning

Establishing strength is the mirror image of anticipating weakness: the discipline of identifying which parts of a design are already carrying load reliably, and deliberately reinforcing and reusing that pattern elsewhere, rather than spending equal effort patching every part of the system evenly. Anticipating a weak point is therefore only half the discipline; the other half is deciding what to do about it once found, and “add more of everything” is rarely the optimum answer.

A tiered architecture — sensor-level processing, an edge tier, and a cloud layer connected over redundant encrypted network paths — can be designed so that the loss of a higher tier degrades the system’s fidelity rather than its function: local anomaly detection and alerting continue at the edge even when cloud connectivity is temporarily lost, rather than the entire monitoring capability failing shut. That is redundancy applied deliberately, at the architectural decision that matters most, rather than duplicated everywhere at a cost the system cannot sustain.

The same principle governs Medallion-style layered data architectures — Bronze, Silver, and Gold layers standardizing ingestion, cleansing, and business transformation across payments and risk analytics. Each layer exists because it lets a downstream failure be isolated and reprocessed from a known-good upstream state, rather than requiring the entire pipeline to be re-run from source. Optimum solutioning, in the industrial and the financial-data context alike, means the same thing: redundancy placed at the specific points where a failure would otherwise cascade, not spread evenly across a system as an undifferentiated safety margin.

5. Polling, Advance Notification, and Proactive Resilience

A system that only reports a failure when a user or downstream process finally hits it has already lost the most valuable window for recovery — the interval between when something starts going wrong and when it becomes visible. Proactive polling — a component periodically checking the health of itself and its dependencies, rather than waiting passively to be asked — is what closes that window.

This is a discipline that applies on both sides of the same problem. In regulated data engineering, it means building the schema-enforcement, deduplication, and anomaly-detection checks that feed centralized log-aggregation and alerting platforms, so that a data-quality regression surfaces as a proactive alert rather than as a wrong number a business team catches downstream weeks later. In edge-resident monitoring architectures, the same instinct belongs in the architecture itself: the sensor-to-hub telemetry link is monitored continuously, not sampled on request, precisely so that a degrading sensor — the weak scenario described above — is caught by the system’s own advance-notification logic before it can corrupt a downstream decision. Advance notification, done well, is not a monitoring feature bolted onto a finished design; it is a structural requirement of the design itself.

6. Engineering for Longevity and Extendability: Systems Built to Sustain and to Grow

A system that works on day one and cannot be maintained on day one thousand has not actually solved the problem it was built for — it has deferred the problem to whoever inherits it. Longevity is a design requirement, not a maintenance afterthought, and it shows up most clearly in how a system handles change over its lifetime rather than in how it performs when new.

Two forms of it are worth naming. The first is operational: remote fleet configuration — the ability to update, retune, or reconfigure a deployed fleet of sensor nodes centrally as conditions or requirements change, rather than requiring a physical visit to every node — is a longevity requirement that has to be designed in from the first architectural decision, because retrofitting it once a fleet is large enough to make manual updates impractical is exactly when it is hardest to do. The second is interpretive, and more often skipped: the data-governance discipline of collecting, curating, and documenting Critical Data Elements so that a system’s definitions remain legible to the next engineer, not just the one who built it. Both are the same bet — that a system’s useful life is determined less by its initial capability than by how cheaply it can be understood, corrected, and extended by someone other than its original author.

There is a third form, and it is the one that turns longevity from a defensive property into a strategic one. Building to last keeps a system alive; building to extend determines what it is still allowed to become. A system whose foundation and frame were specified generously — clean interfaces, explicit contracts, decisions recorded rather than buried in implementation — can absorb a capability nobody had imagined when it was designed. A system whose structure encoded only the requirements of its first release cannot, and the organization discovers this at precisely the moment a market shift or a new technology makes the capability urgent. The design-time question is therefore not only what this system must do today, but what it is plausible that this system will be asked to do by a technology or a business model that does not exist yet — and whether today’s structure would make that a feature or a rebuild. Envisioning, in this sense, is not forecasting; nobody can name the capability in advance. It is the deliberate practice of leaving the structural room for one, and of knowing which parts of the design would have to be torn out if that room was not left.

The organizations that adopt a new capability in a quarter rather than a replatforming cycle are rarely the ones that moved faster under pressure. They are the ones whose foundation did not have to be torn out first.

This is where engineering structure meets business positioning, and why extendability belongs in a strategy conversation rather than only a technical one. Those organizations paid for the structural room years earlier, when it was cheap, and were therefore in a position to say yes when the opportunity arrived. Extendability, in that light, is not a technical luxury deferred until the roadmap allows it. It is the capacity to take a strategic position at all — and like every other load-bearing property here, it is decided long before it is needed.

7. The Structural-Priority Framework: What a Building Teaches Systems Design

Construction practice offers a discipline that software and AI system design often lacks: an explicit, non-negotiable hierarchy of what must be complete before a structure may be occupied, and what may reasonably be finished afterward. A building’s foundation, load-bearing beams, and columns must be fully specified, inspected, and correct — a gap there is invisible until it is catastrophic, and it cannot be corrected after the fact without returning to the foundation itself. Interior partitions, finishes, and cosmetic elements matter for the building’s usability and appeal, but a gap there is visible, correctable, and rarely dangerous. No competent engineer would defer a beam calculation to prioritize a paint finish; just as few would insist every interior wall be finalized before the foundation is poured.

Systems and AI solution design benefits from the same explicit hierarchy, and rarely gets it. Requirements-prioritization methods like MoSCoW — developed by Dai Clegg in 1994 and carried forward through the Dynamic Systems Development Method (DSDM), which sorts requirements into Must-have, Should-have, Could-have, and Won’t-have this time — provide the mechanics for that sorting. What they do not supply on their own is the structural judgment for where the line between “must” and “should” actually sits. The building analogy supplies that judgment: a requirement belongs in the “foundation and frame” tier not because a stakeholder calls it important, but because a gap there is invisible until failure and uncorrectable without rework at the root.

Five structural tiers carry that mapping through, building term to system term, so the judgment is traceable rather than merely asserted:

Foundation. In a building: load-bearing ground works; a defect is invisible until the structure fails. In a system or AI solution: data integrity, security boundaries, and the core failure-handling logic a system’s correctness depends on.

Beams and columns. In a building: the load-bearing frame; every connection must be specified and inspected. In a system or AI solution: compliance-critical business logic, safety interlocks, and the primary failure-recovery paths.

Load-bearing walls. In a building: structural but more localized; a defect is serious but often containable. In a system or AI solution: critical integration points between subsystems — the interfaces most likely to cascade a failure if unspecified.

Partitions. In a building: divides space; wrong today, movable tomorrow without touching the structure. In a system or AI solution: secondary features, non-critical reporting views, workflow conveniences — correct later without redesign.

Finishes. In a building: paint, fixtures, cosmetic detail; last priority, first thing deferred under time pressure. In a system or AI solution: UI polish, nice-to-have automation, cosmetic personalization — genuinely deferrable.

The practical discipline this framework enforces is a single question, asked of every requirement before it is triaged. Call it the silence test: if this is wrong or missing, does the failure surface immediately and get corrected, or does it stay silent until it is structural?

A monitoring system’s handling of a degraded sensor input sits in the foundation tier under that test — a gap there does not produce a visible bug, it produces a confidently wrong maintenance recommendation with no visible symptom until an asset fails unexpectedly. A missing dashboard filter, by contrast, is annoying and entirely correctable after launch. Treating both as equally schedulable “requirements” — as flat backlogs routinely do — is precisely the failure mode the building analogy is built to prevent.

This is also where design thinking’s iterative core gets implemented correctly rather than abandoned. Prototype, test, and refine freely at the partition and finish tiers, where a wrong guess costs a redesign, not a rebuild — that loop is exactly what design thinking is for. At the foundation and frame tiers, the same instinct has to run before the system is built, not iterated on after: through structured edge-case walkthroughs, pre-mortems, and the kind of problem-solving discipline described in Section 2, applied up front, because redesigning after the fact means tearing out a load-bearing wall to fix the column behind it. Design thinking and structural priority are not competing philosophies; they are the same discipline applied to two different tiers, with two different tolerances for being wrong the first time.

8. The Framework in Practice: A Reference Grid for Technology, Data, and AI Solutioning

The mapping in Section 7 explains the framework; the grid below is meant to be used. It restates the same five tiers as a working reference for technology, data, and AI solutioning, where the question is rarely whether a requirement matters and almost always which requirements may be safely deferred when the schedule tightens. Five columns carry the judgment: how the failure behaves, what the tier typically contains in general technology solutioning, what it contains in a data or AI system specifically, what review standard applies before anything is built, and whether deferral is legitimate at all. Read left to right, a row is a decision; read top to bottom, the grid is a triage order.

Two properties of the grid are worth stating explicitly, because they are what make it a triage tool rather than a taxonomy. First, the tier is decided by the failure’s behavior, not by the requester’s seniority or the strength of the business case — a foundation-tier gap sponsored by nobody outranks a finish-tier request sponsored by everybody. Second, the deferral column is deliberately asymmetric: deferral below the frame is normal engineering practice and should be recorded rather than avoided, while deferral at or above it is not a scheduling decision at all. It is a decision to occupy a building whose frame was never finished, and it should be escalated in those terms.

9. The Missing Foundation: Vision, Role Clarity, and Cultural Cohesion

Everything above assumes a question can be answered: what is this system actually for? A framework that sorts requirements by whether their failure is silent depends entirely on someone being able to say what a correct outcome looks like. Where that answer is absent, contested, or quietly different in each stakeholder’s head, the sorting cannot be performed at all, and no amount of methodology substitutes for it.

This is, in practice, where a great deal of modern delivery fails, and the usual diagnosis is wrong. The problem is rarely that teams are insufficiently agile. Most organizations run the ceremonies faithfully — the stand-ups, the boards, the iteration reviews, in one branded variant or another. The problem is that the ceremonies are running on an absent vision. A team can execute a flawless two-week cadence while individual members hold materially different beliefs about what the work is ultimately for, and the cadence itself will never surface the discrepancy, because nothing in it asks.

Ask several stakeholders, separately, what the core objective of a given role is. If the answers come back varied, vague, or mutually inconsistent, the finding is not that communication could be better. It is that the function responsible for holding and transmitting the vision is unstaffed.

That diagnostic is worth running deliberately, and it fails most often for contract and specialist roles. Someone was hired against a job description and a skills match — a necessary and entirely insufficient condition — and no one took responsibility for connecting that hire to a mission.

What makes this worth naming here, rather than filing under organizational culture, is that the framework cited earlier already anticipated it. DSDM — the method that carries MoSCoW, referenced in Section 7 — rests on eight principles, two of which speak directly to this: “build incrementally from firm foundations” and “communicate continuously and clearly” (Agile Business Consortium, DSDM Agile Project Framework). The first is, almost word for word, the structural thesis of this piece, arrived at independently and from a different direction. The second treats communication not as a soft complement to the engineering work but as a standing principle of the method itself.

DSDM goes further, and this is the part most often discarded in adoption: it defines a named project-level role, the Business Visionary, responsible for making sure the delivered solution meets the business vision, approving the high-level requirements as a coherent set reflecting what the business actually needs, ensuring those requirements are prioritised and evaluated in business terms against that vision, and — in the handbook’s own phrase — promoting the translation of the business vision into working practice. Formal acceptance at the end of each timebox runs through that role as well, so the responsibility is continuing rather than a one-time kickoff address. Organizations routinely adopt DSDM’s ceremonies and prioritization mechanics while leaving that role unfilled — and then attribute the resulting drift to the method.

That last phrase is worth sitting with, because it names the failure precisely. The job is not to hold the vision. It is to translate it into working practice, continuously, as practice changes.

The leadership implication follows directly. The function is not to issue a vision once and consider it transmitted. It is to restate it as conditions change, to make adjustments legible at the moment they happen, and to recalibrate deliberately rather than letting each team infer a new direction from the absence of one. Leadership measured this way is an enabler or a bottleneck depending on a single behavior: whether the person holding the vision keeps making it available, or becomes the sole point through which meaning has to be requested.

Apply the silence test to the delivery system itself and the conclusion is uncomfortable but clean. Does a gap in role clarity announce itself immediately, or does it stay silent until it is structural? It stays silent. A team with unclear objectives produces work on schedule, attends every ceremony, and reports green — right up to the point where the delivered thing turns out to solve a problem nobody had, or three subsystems turn out to encode three different interpretations of the same requirement. There is no visible bug. There is no failing test.

Cultural cohesion, role clarity, and a continuously communicated vision are not finish-work. They are foundation — in the delivery system rather than the delivered one — and they are almost never triaged that way.

10. Conclusion

None of the practices here — design thinking, systems thinking, problem solving, edge-scenario anticipation, targeted redundancy, proactive polling, designing for longevity, engineering for extendability, or staffing the vision function that makes any of it decidable — is new in isolation. What changes in the AI era is the cost of skipping any one of them, because the gap between a flawed decision and its consequence has compressed from “a human notices before it matters” to “the system has already acted.” The Structural-Priority Framework offered here is one practitioner’s attempt to make that discipline explicit and teachable: build the foundation and the frame completely, every time, and treat everything else as genuinely, safely deferrable — not because the finishes do not matter, but because, unlike the foundation, they can still be fixed after the building is standing.

What that discipline buys is not only a system that lasts. It is a system still capable of becoming something its designers never specified.

References

Agile Business Consortium, DSDM Agile Project Framework — Principles, and Roles and Responsibilities (formerly the DSDM Consortium), accessed August 2026. https://www.agilebusiness.org/dsdm-project-framework/roles-and-responsibilities.html

National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100–1. https://doi.org/10.6028/NIST.AI.100-1

“MoSCoW method,” Wikipedia, accessed August 2026. https://en.wikipedia.org/wiki/MoSCoW_method

Originally published on Medium.

Robotics Digital Intelligence Begins in the Control Loop

Reno Rajan Christy — Sat, 31 Oct 2026 07:31:01 +0000

Mechatronics is one of the few engineering disciplines with a definition tight enough to argue about. The IEEE/ASME Transactions on Mechatronics, established in 1996, describes its subject as “the synergetic integration of mechanical engineering with electronic and intelligent computer control in the design and manufacture of industrial products and processes.” The operative word is integration: the artifact is designed as one thing, and a decision made in the control software is a decision about the gearbox.

For most of that history, “intelligent computer control” meant deterministic control. A transfer function, a state machine, a tuned loop — specified in advance, verifiable against the specification, and failing in ways an engineer could enumerate. The change now underway is narrow and consequential. Inference is becoming a component that lives inside the machine rather than a service the machine calls. The control loop acquires a learned element, and that has downstream effects on design, safety, verification, and where the value actually shows up.

What changes when inference becomes a part

Edge AI here means inference executed on or beside the machine rather than in a remote service. Physical AI means a system that senses and acts on the physical world rather than producing text or charts for a person to read. Robotics digital intelligence is the useful shorthand for what the combination produces: a machine that interprets its own state and acts on it, rather than executing a plan computed somewhere else. All three terms are used loosely in the market; the distinction that matters to a designer is none of them. It is the difference between a component and a service.

A component has a line on the bill of materials, a power draw, a thermal contribution, a failure rate, and a defined behavior at its interfaces. A service has an availability target and a contract. Moving inference across that boundary converts a commercial property into a physical one. The model now competes for watts with the actuators, adds heat inside the same enclosure, and has to survive the same vibration and temperature range as everything else in the housing. Enclosure volume, heat path, and power budget become model-selection constraints — which is precisely the kind of cross-domain coupling mechatronics exists to handle, and precisely the kind that no single discipline owns.

There is a second effect, quieter. ISO 8373:2021, the robotics vocabulary standard, defines a robot as a “programmed actuated mechanism with a degree of autonomy … to perform locomotion, manipulation or positioning,” where degree of autonomy is assessed by the quality of the machine’s decision-making and its independence from a human. A learned element raises autonomy by that definition. It does not, on its own, raise anyone’s ability to state what the machine will do.

Why put it inside the machine at all

Three reasons, in order of how binding they are.

Time. A control loop has a cycle budget measured in milliseconds or less, and everything inside the loop needs a worst case. A network round trip is a distribution, not a bound. Anything whose latency cannot be bounded belongs outside the loop by construction, which is the whole argument in one line.

Availability. A machine whose function depends on a link has made connectivity a single point of failure. Mechanical engineers already know how to reason about single points of failure, and generally reject them in load paths. The same instinct applies here and is often not applied, because the dependency is invisible on the drawing.

Signal. This is the underrated one, and it carries most of the value. The measurements that reveal a machine’s condition earliest are the dense ones: full-rate vibration, current and voltage waveforms, acoustic emission. Shipping them upstream means downsampling or summarizing them first, which discards exactly the features that carry early information. Running inference at the source lets a model see the signal at its native rate. The gain is not a cheaper bill. It is a class of evidence that was previously unusable becoming usable.

The learned element belongs inside a deterministic envelope

That is not a stylistic preference. ISO 13849–1:2023 defines a safety-related part of a control system and assigns it a performance level — a discrete level specifying the ability to perform a safety function under foreseeable conditions. IEC 61508, the generic functional safety standard for electrical, electronic, and programmable electronic safety-related systems, assigns safety integrity levels on the basis of systematic capability, architectural constraints, and probability of dangerous failure. Both frameworks assume the same two things: that the intended function can be stated, and that an implementation can be shown to deliver it with a quantified failure probability.

A learned element is specified by its training distribution and evaluated statistically. Neither standard has a natural slot for that. So the practical architecture puts torque limits, stop functions, and interlocks in the rated deterministic layer, and lets the model shorten a cycle, adjust a set point, or flag a degrading bearing — inside limits it has no authority to move.

A learned element earns its place by making a machine better within limits it cannot change. The moment it can change the limits, everything upstream of it has to be certifiable, and nothing about how such elements are built makes that easy.

The verification problem the discipline has not solved

Standards bodies have acknowledged the gap without closing it. ISO/IEC TR 5469:2024, Artificial intelligence — Functional safety and AI systems, published in January 2024, sets out a qualitative view of functional safety risk across combinations of AI technology class and usage level, describes a three-stage realization principle for using AI technology in safety-related systems, and devotes separate clauses to verification and validation challenges and to control and mitigation measures. Its status is worth reading carefully: a technical report is informative rather than normative. The subject was live enough to require a document and unsettled enough that the document could not yet be a requirement.

NIST’s AI Risk Management Framework (AI 100–1, 2023) supplies the complementary organizational discipline, and it is a management framework rather than a verification method. Neither document hands a machine designer a test to run.

What is actually missing is a treatment of the failure mode. Conventional component failure is bounded and detectable: a sensor opens circuit, an encoder loses counts, a driver latches. A learned element fails by being confidently and plausibly wrong in a region of input space it was never shown, and that failure leaves no signature at the interface. Detecting it requires a second, independent estimate — a physics-based model, redundant sensing, or a plausibility bound derived from the mechanics of the machine itself. Designing that independent check, not selecting the model, is where the engineering effort belongs.

Where it lands first: robot cells and shared workspaces

Industrial robotics is the leading case because the installed base is large and already instrumented. The International Federation of Robotics reports 542,000 industrial robots installed worldwide in 2024, the fourth consecutive year above 500,000 units, bringing operational stock to 4,664,000 units, up 9 percent year over year; Asia accounted for 74 percent of new deployments against 16 percent in Europe and 9 percent in the Americas, with U.S. installations at 34,200 units, down 9 percent. The IFR projects roughly 575,000 installations for 2025, a figure that should be read as a forecast rather than a result. Learned components will mostly arrive as retrofits into that stock, not as a new category of machine — which is why robotics digital intelligence will show up first as an upgrade to installed equipment rather than as a new class of robot.

The standards moved with it. ISO 10218–1:2025, the third edition, published in February 2025, replaced the 2011 edition; per its scope, it incorporates safety requirements for industrial robots used in collaborative applications — content formerly carried in ISO/TS 15066:2016 — and adds requirements for cybersecurity to the extent it bears on robot safety, alongside clarified functional safety requirements and a robot classification scheme.

Collaborative operation is where perception quality becomes a safety-relevant engineering quantity. Under speed and separation monitoring — one of four collaborative modes treated in ISO/TS 15066:2016, alongside safety-rated monitored stop, hand guiding, and power and force limiting — the system maintains a protective separation distance from the person and modulates robot speed to preserve it. Throughput is therefore a direct function of how quickly and how accurately the machine can locate a human. A better perception model buys cycle time and changes a safety margin through the same variable. Very few design problems put economic value and safety consequence on the same axis; this one does, and the design has to hold both at once.

Smart human–computer–machine interaction spaces

Call a smart interaction space one where a person, a computing system, and a machine share physical volume, and the machine acts on an inferred model of the person. Two consequences follow, and both are design obligations rather than features.

First, the model of the human is a safety-relevant component. Once machine behavior depends on an inference about where someone is, where they are heading, or whether they are attending, that inference inherits a specification burden it never carried when it only drove a display.

Second, legibility becomes a safety property. ISO 9241–210:2019 sets out requirements and recommendations for human-centered design across the life cycle of computer-based interactive systems. Applied to a machine that moves, the principle sharpens: the person sharing the space has to be able to predict what it will do next. A machine that is technically safe but behaviorally unpredictable gets worked around, and a safety function people route around is not performing a safety function.

Where it goes next, and when

Outside the robot cell, the same shift reaches ordinary installed equipment — pumps, fans, handling gear, building systems. The design consequence there is that the sensor stops being an instrument and becomes part of the model. Calibration drift, mounting variation, and mechanical aging are no longer measurement nuisances to be corrected; they are distribution shift, and they degrade inference rather than merely biasing a reading. Where the accelerometer mounts and how the enclosure resonates set the model’s input distribution for the service life of the unit. Nobody in a conventional org chart owns that decision, which is the clearest sign it is a mechatronics decision.

As for when: the institutional clock is already running. NIST published its AI risk framework in 2023, ISO/IEC issued the functional safety and AI technical report in January 2024, and ISO published the first substantive revision of the industrial robot safety standard in fourteen years in February 2025. Three consecutive years of movement by standards bodies is not a forecast; it is a record. Procurement language and insurance requirements historically follow published standards with a lag, so machines being designed now are likely to be sold into a market that asks for evidence rather than assurances.

Three practices follow, and none require a new technology. State the authority partition explicitly in the design documentation: what the learned element is permitted to change, and what it is not. Specify the independent check before selecting the model, including which physics supplies the second estimate. And treat the mechanical mounting as part of the model specification, because it is.

Mechatronics has always been the discipline that refuses to let mechanical, electronic, and control decisions be made separately. A learned element in the loop is simply the next thing that cannot be designed in isolation — and the first one whose failures do not announce themselves. Robotics digital intelligence will be judged, in the end, not on what the model can infer but on whether the machine around it was designed to contain a component that can be wrong.

References

IEEE/ASME Transactions on Mechatronics (published since 1996), Aims and Scope, IEEE Xplore, accessed August 2026. https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=3516

International Organization for Standardization (2021), ISO 8373:2021 — Robotics — Vocabulary, accessed August 2026. https://www.iso.org/standard/75539.html

International Organization for Standardization (2025), ISO 10218–1:2025 — Robotics — Safety requirements — Part 1: Industrial robots, accessed August 2026. https://www.iso.org/standard/73933.html

International Organization for Standardization (2016), ISO/TS 15066:2016 — Robots and robotic devices — Collaborative robots, accessed August 2026. https://www.iso.org/standard/62996.html

International Organization for Standardization (2023), ISO 13849–1:2023 — Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design, accessed August 2026. https://www.iso.org/standard/73481.html

International Electrotechnical Commission (2010), IEC 61508–1:2010 — Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 1: General requirements, accessed August 2026. https://webstore.iec.ch/en/publication/5515

ISO/IEC (2024), ISO/IEC TR 5469:2024 — Artificial intelligence — Functional safety and AI systems, accessed August 2026. https://www.iso.org/standard/81283.html

National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100–1, accessed August 2026. https://doi.org/10.6028/NIST.AI.100-1

International Federation of Robotics (2025), World Robotics 2025 — Global Robot Demand in Factories Doubles Over 10 Years, accessed August 2026. https://ifr.org/ifr-press-releases/news/global-robot-demand-in-factories-doubles-over-10-years

International Organization for Standardization (2019), ISO 9241–210:2019 — Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems, accessed August 2026. https://www.iso.org/standard/77520.html

Originally published on Medium.

How an AI Agent Actually Works, One Capsule at a Time

Reno Rajan Christy — Sat, 31 Oct 2026 07:29:50 +0000

“Agent” may be the most overloaded word in technology this year. Some people mean a chatbot with a few plugins. Others mean software that can run a business process end to end. Under the marketing, almost every AI agent does the same thing: it runs a loop. It takes a goal, thinks about it, uses a tool, looks at what happened, and decides what to do next, again and again until the job is done or it asks for help.

The research idea behind most of today’s agents is simple. The 2022 ReAct paper (published at ICLR 2023) proposed using language models “to generate both reasoning traces and task-specific actions in an interleaved manner, allowing for greater synergy between the two.” Think, act, observe, think again. Everything else is engineering around that loop.

This article draws that loop as ten capsules. The size of each capsule shows how much complexity it hides, on my own illustrative scale. The point of drawing it this way is practical: the big capsules are where agents fail, and where your design effort should go.

Figure 1. The agent loop as ten capsules. Capsule size and the dots show relative complexity (the author’s illustrative scale). Steps 3 to 10 repeat until the goal is met.

The ten capsules

1. Goal intake (small). The agent receives a request: “Find out why last night’s data loads failed and fix what you safely can.” Small, but not trivial. A vague goal produces a vague agent, so good systems restate the goal and its limits before starting.

2. Context and memory (medium). What does the agent already know? It gathers relevant documents, past conversations, system state and notes from earlier runs. Most “the agent hallucinated” stories are really “the agent had the wrong context” stories.

3. Planning (large). The agent breaks the goal into steps: list the failed jobs, read their error logs, group them by cause, fix the safe ones, report the rest. This is the first big capsule. A bad plan wastes every step after it, and a plan that is too rigid cannot adapt when step two reveals a surprise.

4. Tool selection (small to medium). For the current step, which tool fits: a database query, a log search, a code runner, an email? Agents are only as capable as the tools they are given, and only as safe as the tools they are denied.

5. Guardrail check (medium). Before acting, is this action allowed and safe? Does it touch production? Is it reversible? Does it need a person’s approval? This capsule is easy to skip in a demo and essential in real use.

6. Act (small to medium). The agent calls the tool. The call itself is usually simple; the risk lies in what it changes.

7. Observe (small). The agent reads the result: rows returned, an error message, a file written.

8. Evaluate and reflect (large). Did that work, and if not, why not? This is the second big capsule, and the one that separates useful agents from expensive ones. The 2023 Reflexion paper showed one way to strengthen it. Its agents “verbally reflect on task feedback signals, then maintain their own reflective text in an episodic memory buffer to induce better decision-making in subsequent trials.” In plain terms, the agent writes itself a note about what went wrong and reads it before trying again.

9. Update memory (small to medium). The agent keeps what it learned, such as “job X fails when the upstream file arrives late,” so the next run starts smarter.

10. Finish, loop or hand off (medium). Is the goal met? If not, go back to planning. If the agent is stuck, or the next step is risky, hand off to a human with a clear summary. Knowing when to stop is a feature, not a failure.

Why capsule size matters

When you draw an agent this way, a pattern jumps out. The complexity is not in the tool call, the part most demos show. It concentrates in three places: context, planning and evaluation. That is where agents go wrong, and it tells you where to spend your engineering effort.

Context and memory. What typically goes wrong: stale, missing or irrelevant information. Design tip: retrieve narrowly; record where each fact came from.
Planning. What typically goes wrong: plans that are too long, too rigid or aimed at the wrong goal. Design tip: plan a few steps ahead, then re-plan after each observation.
Guardrail check. What typically goes wrong: actions that are irreversible or out of scope. Design tip: list what the agent may never do; require approval for irreversible steps.
Evaluate and reflect. What typically goes wrong: the agent declares success too early, or loops forever. Design tip: define “done” up front; cap retries; check results against evidence, not the agent’s own opinion.
Finish or hand off. What typically goes wrong: silent failure, or an unhelpful “I could not complete this”. Design tip: hand off with what was tried, what was learned and what is needed.

A worked example: one agent, one night of failed data loads

Here is the loop on a problem every data team knows. Two overnight data loads have failed.

Goal intake. Find the causes, and safely rerun what can be rerun.
Context. The agent pulls the job schedule, the last run statuses and the runbook.
Planning. It lists the failed jobs, reads each error, groups them by cause, reruns only the jobs whose cause is known to be transient, and reports the rest.
First failure: a timeout. The agent chooses the log-search tool. The guardrail check passes, because reading logs is safe. It acts, observes a timeout error, and evaluates: timeouts on this job are known to be transient. It reruns the job, which requires another guardrail check: reruns are allowed for this job type, so it proceeds. It observes success.
Second failure: a schema change. A new column appeared upstream. The evaluation step recognizes this as not safe to fix automatically. Changing a table definition is out of scope.
Finish and hand off. The agent writes a summary: one job rerun successfully, and one needs a person to approve a schema change, with the evidence attached. It records the lesson in memory.

No step was magic. The value came from the big capsules: good context, a plan that adapted, and an evaluation step honest enough to stop.

A checklist before you build or buy an agent

Goal: can the agent restate the goal and its limits?
Context: where does its information come from, and how fresh is it?
Plan: does it re-plan after surprises, or push on regardless?
Tools: does it have only the tools it needs?
Guardrails: what can it never do, and what needs approval?
Evaluation: how does it know it succeeded, other than saying so?
Hand-off: when it gets stuck, does it hand off to a person with a useful summary?
Memory: does it get better over time, and can you inspect what it remembers?

The takeaway

An AI agent is not a mysterious digital employee. It is a loop of ten capsules, and three of them — context, planning and evaluation — hold most of the complexity. Draw your agent this way before you build it. The sizes of the capsules tell you where it will break, and where your engineering hours will pay off.

References

S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan and Y. Cao, “ReAct: Synergizing Reasoning and Acting in Language Models,” ICLR 2023. arXiv:2210.03629
N. Shinn, F. Cassano, E. Berman, A. Gopinath, K. Narasimhan and S. Yao, “Reflexion: Language Agents with Verbal Reinforcement Learning,” 2023. arXiv:2303.11366

Capsule sizes reflect the author’s judgment and are illustrative, not measured. The views expressed are the author’s own.

I used an AI writing assistant to help draft and edit this article. I reviewed and revised the text and checked every source.

Originally published on Medium.

The Bio-Computational Stack: One Pipeline from Molecule to Individualized Cure

Reno Rajan Christy — Sat, 31 Oct 2026 07:29:14 +0000

Every living thing runs on a small set of molecular rules. Information stored in nucleic acids is copied, read, and used to build proteins, and proteins in turn do most of the chemical work of the cell. Francis Crick stated the principle behind that flow as the “central dogma of molecular biology” and restated it in Nature in 1970. Half a century later, the rules have not changed. What has changed is our ability to read them at scale, reason about them with AI, and act on them with robots.

This essay was prompted by an introductory biochemistry lecture, Biochemistry 101: The Molecular Logic of Life, and by a simple question it raised for me as a data engineer. If the logic of life is a pipeline, from molecule to function, why are the systems we use to study and treat it still built as islands? Laboratories, instruments, genomic databases, hospital records and AI models usually sit in separate systems, owned by separate teams, and speak separate formats. The opportunity of the next decade is to join them into one bio-computational stack: a single pipeline that turns biological matter into data, data into predictions, and predictions into individualized decisions, and then feeds the result back down to the bench.

Why now: three signals

Three published results show that each piece of the stack now works on its own.

AI can now predict protein structure from sequence. The AlphaFold team reported in Nature (2021) “the first computational method that can regularly predict protein structures with atomic accuracy even in cases in which no similar structure is known,” with “accuracy competitive with experimental structures in a majority of cases” in the CASP14 assessment.
Robots can now run experiments without a person at the bench. In a 2020 Nature study, a mobile robot “operated autonomously over eight days, performing 688 experiments within a ten-variable experimental space.” Its search “identified photocatalyst mixtures that were six times more active than the initial formulations.” The authors describe the approach as “automating the researcher rather than the instruments.”
Population-scale clinical and genomic data is being assembled. The U.S. All of Us Research Program, described in the New England Journal of Medicine (2019), “plans to enroll a diverse group of at least 1 million persons in the United States in order to accelerate biomedical research and improve health.”

Prediction, automation and data each exist today. What does not yet exist at scale is the architecture that connects them.

The six layers of the stack

Figure 1. The bio-computational stack. Information is synthesized upward, from molecule to decision. Instructions flow downward, from decision to experiment.

Layer 1: the molecular layer. DNA, RNA, proteins and metabolites: the substrate. Nothing in the stack is real unless it is anchored here.

Layer 2: the physical interface, or wet lab. Liquid handlers, bioreactors, sequencers and mobile robots. This is the layer that turns a digital instruction (“prepare these 96 variants”) into a physical experiment. Its engineering problems are the same as in any factory: calibration, throughput, contamination, and knowing exactly what was done to which sample.

Layer 3: the analytical layer. Sequencing, mass spectrometry, chromatography, spectroscopy and imaging measure the physical and chemical characteristics of what the lab produced. This is where matter becomes measurement, and where most of the noise enters.

Layer 4: the data plane. Genomic profiles, instrument outputs, and genetic and clinical records meet here, under common identifiers, provenance and consent. This is the layer most often missing, and it is the one I would build first (more below).

Layer 5: the AI computational layer. Here data becomes prediction:

models that predict structure or response;
generative models that propose new candidates;
over time, a patient digital twin, a continuously updated model of one person’s biology that can be tested in silico before anything reaches the patient.

Layer 6: the synthesis and decision layer. Predictions become actions: the next experiment to run, the candidate to make, and, in the clinic, the decision a physician signs.

The direction matters. Information is synthesized upward: molecule, then measurement, then data, then model, then decision. Instructions flow downward: decision, then design, then robot, then molecule. A stack that only goes up is a reporting system. A stack that also goes down is a discovery engine.

From static records to a dynamic predictive system

Most biomedical data today is a snapshot: a sequence taken once, a lab panel from last spring, a diagnosis coded at discharge. The bio-computational stack turns snapshots into a dynamic predictive system, one that updates as new measurements arrive and gets better at predicting each individual the more it learns.

At the top of the stack sits a closed loop that laboratory scientists already know as design–make–test–learn:

AI proposes candidates.
Robots make them.
Instruments test them.
Models learn from the results.

The loop then turns again. The robotic chemist above is an early, narrow example of that loop closing without a human at every step.

Figure 2. The closed loop at the top of the stack. In medicine, a human signs off at every irreversible step.

A solution design approach: seven principles

Building this is less about any single model than about the architecture around the models. Seven principles follow from treating it as one system.

Build the data plane first. Common identifiers for samples, patients and experiments; shared vocabularies; and provenance recorded with every measurement: which instrument, which protocol, which version. Without this, every AI model is trained on a different, undocumented version of the truth.
Give every instrument a standard interface. Robots and analyzers should expose their capabilities and results through documented, machine-readable interfaces, so the stack is not rebuilt each time a lab changes vendors.
Close the loop by design, with human sign-off at irreversible steps. Automate the reversible steps: simulation, sample preparation, analysis. Require a named person to approve anything that cannot be undone, above all anything that reaches a patient.
Carry uncertainty all the way up. A prediction without a confidence estimate should not drive an experiment, and never a treatment. Each layer should pass its uncertainty to the next.
Make privacy and consent part of the architecture. Consent should travel with the data it governs. Where data cannot move, move the computation to the data, so that models can be trained where the records live.
Validate along a ladder. A candidate climbs from in silico to in vitro to clinical evidence, and the stack should record which rung every claim has reached.
Keep a complete audit trail. Regulators, clinicians and patients will need to know why the system recommended what it did. Record every model version, input and decision.

Where it applies

The same stack could serve several frontiers. Each one needs the same data plane, the same closed loop and the same safeguards:

Rare and complex diseases, where individualized profiles matter because no large population shares the condition.
Oncology, where tumors differ from patient to patient.
Antimicrobial resistance, where fast design–make–test cycles could keep pace with evolving pathogens.
Biomanufacturing, where the same loop tunes how a therapy is produced, not only what it is.

The long-term promise is bio-synthetic engineering of individualized cures: therapies designed, tested and produced for one person, at a cost and speed that make them practical.

What stands in the way

Honesty about the limits is part of good design:

Biology is noisier than software. Measurements drift and batches differ, and a model can only be as good as the provenance of its data.
Predictive accuracy does not equal clinical benefit. Every individualized therapy must still earn its place through clinical evidence and regulatory review, and that is as it should be.
Equity has to be designed in. If the data plane represents only some populations, the predictions will serve only some patients. That is one reason large, diverse programs like All of Us matter.

The takeaway

The pieces are already on the table: models that read molecules, robots that run experiments, and population-scale data. What connects them is an architecture: a data plane that makes every measurement trustworthy, an AI layer that turns data into calibrated predictions, and a decision layer that closes the loop back to the bench with a human hand on every irreversible step. The engineers who can build that stack end to end, and not just its parts, will shape how quickly individualized medicine moves from promise to practice.

References

F. Crick, “Central Dogma of Molecular Biology,” Nature, vol. 227, pp. 561–563, 1970. doi:10.1038/227561a0
J. Jumper et al., “Highly accurate protein structure prediction with AlphaFold,” Nature, vol. 596, pp. 583–589, 2021. doi:10.1038/s41586–021–03819–2
B. Burger et al., “A mobile robotic chemist,” Nature, vol. 583, pp. 237–241, 2020. doi:10.1038/s41586–020–2442–2
The All of Us Research Program Investigators, “The ‘All of Us’ Research Program,” New England Journal of Medicine, vol. 381, pp. 668–676, 2019. doi:10.1056/NEJMsr1809937
Biochemistry 101: The Molecular Logic of Life & Essential Biological Chemistry, Sleepy Science Stuff (YouTube). Cited as inspiration only.

The views expressed are the author’s own.

I used an AI writing assistant to help draft and edit this article. I reviewed and revised the text and checked every source.

Originally published on Medium.