Lukas Paul Streiff | Practical AI • Work Platforms • EAM

 A system rarely becomes hard to replace because of one feature. It becomes hard to replace because, over time, too much behavior accumulates around it. By the time teams start talking about replacement, they are usually not evaluating a product anymore. They are confronting years of embedded assumptions, hidden routines, and interface logic that no longer exists anywhere else. 1. Replacement Usually Fails at the Edges When organizations discuss replacement, attention usually goes to the visible core: the database engine, the platform, the application, the API. In practice, replacement rarely fails at the core first. It fails at the edges: scheduler jobs, exports, drivers, reports, permissions, monitoring, admin scripts, and exception handling. The product is only one layer of the dependency. The harder part is everything that accumulated around it without ever being named as architecture. 2. Compatibility Solves Only the Visible Layer Compatibility is still useful. Syntax support,...

 Most interface problems are not caused by missing architecture. They happen because an interface that “basically works” stays in place after the business has already started relying on it. In a tighter market, that creates a difficult decision. The goal is not to make the integration landscape look more strategic. The goal is to restore reliability without adding a level of complexity the organization cannot carry. 1. Start with the Failure Mode An unreliable interface is not a single condition. It is usually a mix of delayed transfers, duplicate records, partial updates, status mismatches, or data that arrives technically but fails operationally. That distinction matters. Some interfaces are unstable because the implementation is weak. Others are unstable because the business process has outgrown the structure around it. Those are different problems. They should not receive the same solution. 2. Fix the Existing Interface When the Process Is Still Stable Optimizing the current in...

Automation problems rarely begin in the logic itself. They begin where assumptions meet reality: at the interfaces between systems, files, permissions, timing, and people. In pilots, these edges are often invisible. In production, they are usually the first place where things start to break. 1. Logic Is Usually Not the First Problem When automation fails, teams often assume the core logic must be wrong. In practice, that is rarely the first issue. The calculation, transformation, or decision logic often works exactly as intended in isolation.  What breaks are the surrounding conditions: a file arrives late, a field changes format, a permission is missing, or a downstream step behaves differently than expected. Logic usually survives testing. Interfaces are where production starts to expose reality. 2. Interfaces Are Where Assumptions Collide Interfaces are rarely just technical connectors. They are agreements about format, timing, availability, permissions, and meaning. One system ...

Most problems with AI and automation are not caused by the tools themselves. They happen because solutions move from “prototype” to “production” without basic guardrails. The goal is not heavy governance. The goal is to keep speed — without turning today’s quick win into tomorrow’s maintenance debt. 1. Define “Production” “Production” is not a technical term. It is a responsibility threshold. A solution is in production the moment people start relying on it to make decisions, move money, update records, or automate steps that previously required human judgment. At that point, the question is no longer “does it work?” but “can we operate it safely over time?” 2. One Owner, One Inbox Every production solution needs an owner — a clearly named person or role. Not a team, not “IT”, not “the business”, but one accountable point of contact. If something breaks, drifts, or behaves unexpectedly, there must be one inbox that receives the question and one person who can coordinate the response. O...

1. How “Just a Script” Enters Organizations “Just a script” rarely starts as a bad decision. It usually starts with a real, concrete problem that needs a quick solution: something manual, repetitive, or error-prone. The initial script works, saves time, and relieves pressure. And because it works, it stays. 2. Why Small Solutions Feel Safe at First Small automation solutions feel safe because their impact appears limited. They live close to the problem, are easy to explain, and often depend on a single person who understands both the context and the code. Because the scope feels contained, questions about documentation, testing, and long-term maintenance are postponed. The solution is perceived as temporary, even when it quietly becomes part of daily operations. 3. When Maintenance Was Never Part of the Plan Most scripts are not designed to be maintained. They are designed to solve a problem that exists right now, under the assumption that someone who understands the context will alway...

 AI discussions often focus on capabilities, models, and performance. In practice, most problems arise much earlier — at the question of ownership. 1. Ownership Is the Missing Layer Most AI initiatives fail long before model quality or system performance becomes an issue. They fail at a much more basic level: no one is clearly responsible for what the system does once it leaves the prototype stage. Ownership is the missing layer between “it works” and “it works in production.” Without it, even technically sound solutions slowly drift into ambiguity, risk, and neglect. 2. When Everyone Can Build, No One Owns AI dramatically lowers the barrier to building things. Suddenly, creating a script, a workflow, or a small application feels trivial. The effort shifts from planning and coordination to execution. The unintended side effect is subtle but dangerous: when everyone can build, responsibility becomes diffused. What used to require explicit ownership now often lives in personal fo...

 Intro ChatGPT is the new “Doctor Google” — just for tools and code. 1. The Familiar Misunderstanding Since ChatGPT became available to everyone, I keep seeing a familiar misunderstanding: “If I can ask it, I can just build it myself.” The assumption is simple: if an AI can generate code, scripts, or logic on demand, the step from idea to production suddenly feels trivial. But access to information has never been the same as experience, responsibility, or accountability. 2. We Have Seen This Before: Doctor Google This is not a new phenomenon. Years ago, the same pattern appeared with “Doctor Google.” Suddenly, medical information was available to everyone. Symptoms, diagnoses, treatment options — all just a search away. What did not suddenly appear was medical training, responsibility, or the consequences of getting things wrong. Information became accessible. Experience did not. 3. The Pattern Reappears in Companies Today, the same pattern shows up inside organizations. “We just n...