Skip to main content

About

I'm Irving Montes, a System Engineer based in Zurich, currently working at RHI Magnesita, where I work on industrial systems while increasingly focusing my portfolio on AI-native workflow design.

The throughline is the same in both worlds: make execution observable, reliable, and safe to operate. In industrial environments that means edge platforms, diagnostics, and long-lived support tooling. In projects like Symphony Workspace, it means turning tracker issues into bounded agent runs with reviewable handoffs.

Over the years, I've worked across energy, manufacturing, and industrial machinery sectors—at companies like Siemens Energy, Bystronic, and Capgemini—delivering systems that bridge OT and IT domains. That background shapes how I approach AI workflows today: strong contracts, operational visibility, and systems that can be trusted in real use.

“I build systems that need to work for years, not just ship.”

This principle guides every architecture decision I make—from selecting communication protocols to designing fault tolerance and maintainability into the core of every system.

Technical Expertise

AI Workflow Systems

Agent Orchestration
Workflow Contracts
Proof-of-Work
Observability

Cloud & Edge

Azure IoT Edge
Azure IoT Hub
Docker
Kubernetes

Industrial Systems

Siemens PLC
Allen-Bradley PLC
SCADA
HMI Development

Programming

Python
TypeScript
Elixir
C++

Career Highlights

RHI Magnesita

Current

System Engineer

Leading industrial systems and support architecture while bringing more observability and workflow automation into manufacturing operations.

Siemens Energy

Previous

Automation Engineer

Developed control systems and automation solutions for energy infrastructure projects.

Bystronic

Previous

Software Engineer

Built software solutions for industrial cutting and bending machinery.

Capgemini

Previous

Consultant

Delivered digital transformation and system integration projects for enterprise clients.

How I Think About Engineering

Engineering philosophy shapes how I approach problems, design systems, and build solutions. These principles guide every decision—from architecture to implementation.

01

Problem-Solving Approach

Before writing any code, I focus on understanding the problem deeply. This means spending time with the domain experts, observing how work actually gets done, and identifying the real constraints—not just the stated requirements.

Every system operates within constraints: time, budget, existing infrastructure, and human factors. I design for these constraints rather than ignoring them. A solution that works in theory but fails in practice is not a solution.

I ask why repeatedly until I reach the root cause. Often the obvious problem is a symptom of something deeper. Fixing symptoms wastes time; fixing root causes creates lasting value.

Understand deeply. Design for constraints. Build once, build right.
02

System Design Principles

Modularity is non-negotiable. Systems should be composed of discrete, testable components with clear interfaces. When one part fails, the rest should continue operating. When requirements change, individual components should be replaceable without rewriting the entire system.

Reliability is a feature, not an afterthought. Every system I build includes failure modes, graceful degradation, and recovery paths from day one. If a component fails, the system should know, report it, and continue in a safe state.

Observability enables understanding. Logs, metrics, and traces are essential infrastructure. You cannot operate what you cannot see. I instrument systems comprehensively so that when issues arise, they can be diagnosed quickly without guesswork.

Modularity enables change. Observability enables understanding.
03

Reliability & Maintenance

Industrial systems must work for years, not just until deployment. This changes how you write code, structure deployments, and make technology choices. I optimize for operability and maintainability over novelty.

Simplicity beats cleverness. Complex systems are harder to understand, debug, and maintain. I prefer straightforward solutions using well-understood technologies. Innovation belongs in the problem space, not the tooling.

Documentation is part of the deliverable. A system without documentation is incomplete. I write for the engineer who will maintain this system three years from now—who might be me. Clear documentation saves hours of debugging and prevents catastrophic mistakes.

Systems must work for years. Code is read more than written.

The Core Principle

I build systems that need to work for years, not just ship. This means prioritizing reliability over speed, simplicity over cleverness, and maintainability over trends. Every line of code is a liability; every architectural decision compounds. I choose carefully.