# netrii — Full Content for LLM Context > netrii is a talent-dense network of experts that helps ambitious businesses make sharper decisions about AI and emerging technology — and turn those decisions into practical operating advantage. ## About netrii netrii — a "network of rivers of infinite insights" — is a useful-knowledge network helping SMB leaders turn emerging technology, especially AI, into practical moves that drive growth and efficiency. The name netrii is derived from the concept of a "network of rivers" — a system of flowing knowledge, insights, and expertise that converges to create significant impact. netrii operates on the principle of talent density. Instead of the traditional agency model of junior-heavy teams overseen by a few senior partners, netrii maintains a lean, high-caliber network where everyone is a practitioner. The mission is to close the gap between "knowing about" technology and "knowing how to use it." For ambitious SMBs, this gap is where most value is lost. ### The Ideas Behind netrii Generative AI is a General Purpose Technology — a category that includes transformative innovations like steam power, electricity, and the internet. These technologies don't just improve one sector; they reshape entire economies. The 2025 Nobel Prize in Economics recognized scholars who explained this phenomenon. Joel Mokyr showed how useful knowledge — the accumulation of practical insights and their free exchange — fueled the Industrial Revolution. Philippe Aghion and Peter Howitt formalized creative destruction: the process by which new innovations displace incumbents, forcing continuous renewal and driving sustained growth. netrii exists to help ambitious businesses accumulate useful knowledge about AI tools, apply it practically, and emerge stronger from this period of creative destruction. ### Why Work With netrii - **Independent thinking**: Not a reseller, agency, or implementation partner. Advice is based on what is right for your business, not what generates commissions. - **Conventional meets unconventional**: Grounded in proven frameworks, but willing to challenge assumptions and explore new approaches. - **Practitioner mindset**: Willing to test, learn, and admit what does not work. Theory matters, but so does what actually happens when you try it. ### How netrii Works 1. **Clarify the Real Decision**: Understanding goals, constraints, operating reality, and the decisions that actually matter. 2. **Design Focused Moves**: Designing focused experiments, working sessions, or operating changes that produce signal quickly. 3. **Integrate What Works**: Converting promising ideas into repeatable capability with ownership, operating rhythms, and measurement. ## Services ### Strategic Direction For founders, CEOs, and leadership teams navigating meaningful technology decisions. Produces technology opportunity assessments, priority and sequencing recommendations, and decision frameworks for near-term investments. ### Focused Experiments For product, operations, and innovation leaders who need to turn interest into evidence. Produces use case selection and framing, experiment design and decision criteria, and learning and measurement frameworks. ### Operating Integration For COOs, functional leaders, and teams moving from pilots to durable capability. Produces operating model and workflow design, ownership, KPI, and measurement structures, and scaling playbooks. ### Executive Working Sessions For executive teams and founders who need high-quality thinking with low coordination drag. Produces facilitated leadership sessions, decision memos and synthesis, and action plans. ## Who It's For - **Founder / CEO of a Growing Firm**: Making smarter technology bets while scaling. - **COO or Head of Operations**: Improving efficiency with automation and AI. - **Product or Revenue Leader**: Differentiating products with AI capabilities. - **IT / Tech Lead in a Small Team**: Adopting AI responsibly without overcommitting resources. --- ## Experts ### Arun Batchu **Title**: Founder & Principal Advisor **Profile**: https://www.netrii.com/experts/arun-batchu **Website**: https://www.shilpiworks.com I've spent over 30 years building, leading, and advising on technology at every level. Most recently, I served as VP Analyst at Gartner, helping software engineering leaders navigate AI, development practices, and organizational change. Before that, as VP of Advanced Technologies at UnitedHealth Group, I established R&D centers that incubated business innovations including applied AI. At Best Buy, I served as Director of Technology, driving digital product management and technology strategy. Before these leadership roles, I accumulated a wealth of practical problem-solving skills through consulting engagements across diverse industries. I've also shared this knowledge as an Adjunct Lecturer at the University of St. Thomas in St. Paul, MN, where students praised my real-world approach and investment in their success. Today, I build and operate shilpiworks.com — an AI-powered creative commerce platform where 16+ autonomous agents generate, validate, price, and publish stickers, bookmarks, and laser-cut art on cron schedules. The system uses multi-model AI pipelines (Gemini + GPT-Image-1), decision-trace capture, OCR validation, and outcome linking. It's a living laboratory for the same AI agent patterns I advise clients on. My academic foundation includes degrees in Computer Engineering and Software Engineering, complemented by a Nanodegree in Generative AI. One area where this experience converges is healthcare consumer experience. I've worked closely with CX teams to translate patient and member experience goals into workable systems, workflows, and measurable outcomes. That means bridging the gap between what consumers expect, what operations can sustain, and what enterprise technology actually allows — whether the work involves improving digital journeys, applying AI to service delivery, or turning customer insight into action that holds up under real-world constraints. netrii is the next chapter — a focused, independent useful-knowledge network built to help SMBs navigate technology. I'm the founding member, and the vision is to grow netrii as a talent-dense network of experts who turn insight into decisions, experiments, and operating changes. The gap between "knowing about" technology and "knowing how to use it" is where most value is lost. netrii exists to close that gap for ambitious businesses who don't have the luxury of large innovation teams or unlimited budgets. shilpiworks is the proof that this knowledge is operating-grade, not theoretical. **Credibility Markers**: - Former Gartner VP Analyst — advised software engineering leaders on AI, development practices, and leadership - VP of Advanced Technologies at UnitedHealth Group — led technology R&D and incubated AI innovations - Director of Technology at Best Buy — drove digital product management and technology strategy - Adjunct Lecturer at University of St. Thomas — teaching software architecture with real-world expertise - Degrees in Computer Engineering and Software Engineering, plus Nanodegree in Generative AI - Founder of shilpiworks.com — AI-powered e-commerce platform with 16+ autonomous agents in production **Philosophy**: "I'm going to be playing the role of catalyst somewhere, or somewhere I'll be a connector, and somewhere I'll be a Maven — a creator of new ideas. If I can ask the question in the realm of possibility, then maybe we'll come up with a better solution." --- ### Rick Tanler **Title**: Venture Lead, Care Compass & BI Pioneer **Profile**: https://www.netrii.com/experts/rick-tanler **Website**: https://knowledgeadvantage.net Rick Tanler is a serial software entrepreneur, business intelligence pioneer, and thought leader currently focused on the intersection of human wisdom and artificial intelligence. With over 35 years of experience, he is best known for founding and leading Information Advantage, Inc., a company that defined the early landscape of data warehousing and business analytics. In the early 1990s, Rick founded Information Advantage, serving as CEO and Chairman. Under his leadership, the company grew from a startup to over 650 employees in eight years, securing major clients like Target, 3M, Cargill, and Mastercard. He successfully navigated the company through an IPO before its acquisition by Computer Associates in 1999. During this era he also authored The Intranet Data Warehouse (Wiley, 1997) — the first guide to combining corporate data warehouses with intranets — a foundational text that captured the methods he and his peers were pioneering in real time. Rick has transitioned from traditional data analytics to a philosophy centered on 'Liquid Intelligence'—the idea that intelligence must flow and adapt to uncertainty rather than remaining static. He argues that while AI serves as a 'bulldozer' to clear data, human wisdom is required to navigate ambiguity and consequences. Rick leads netrii's Dementia Project — 'Understanding Dementia' — a free, comprehensive online guidebook with 15 evidence-based chapters and an interactive Knowledge Portal mapping over 200 dementia-related concepts. The guidebook supports families and caregivers navigating one of the hardest challenges a family can face, and demonstrates how thoughtful AI technology can serve genuine human needs. Currently, Rick is collaborating with Arun Batchu to operationalize his theories into 'Wisdom as a Service' or the 'River of Infinite Insight'. His goal is to build a peer-to-peer network of experts to capture and distribute high-value, 'tribal knowledge' that AI models alone cannot generate. **Credibility Markers**: - Founder & CEO of Information Advantage (IPO Success) - Ernst & Young Entrepreneur of the Year (1999) - Author of "The Intranet Data Warehouse: Tools and Techniques for Building an Intranet-Enabled Data Warehouse" (Wiley, 1997) — a foundational BI text, available on Amazon - Pioneer at Metaphor Computer Systems (Xerox PARC spinoff) - Strategic Analytics lead at PepsiCo, McKesson, and Dial Corp - Project lead for Understanding Dementia — free 15-chapter guidebook + 200-concept Knowledge Portal (netrii Built by Us) **Philosophy**: "Intelligence must flow and adapt to uncertainty. While AI is a powerful tool for processing data, human wisdom is required to navigate the ambiguity and consequences of the results." --- ### David Quimby **Title**: Advisory Circle & Systematic Innovation Expert **Profile**: https://www.netrii.com/experts/david-quimby **Website**: https://innovationradiation.com David Quimby is a patented inventor, entrepreneur, and principal at Innovation Radiation, where he specializes in systematic innovation, experimental design, and technology forecasting. In a career spanning several decades, David has practiced and innovated at the forefront of human-computer interaction and Web architecture. As the founder and CEO of Adaptive Avenue, David developed a pioneering Web-personalization and media distribution platform. His work in dynamic creative optimization and personalized content delivery was literally decades ahead of its time, earning endorsements from industry legends like Doug Engelbart for its human-centric design. David's expertise is grounded in deep analytical rigor, with a background that includes environmental scanning and technology forecasting at Stanford Research Institute (SRI) and technical / economic feasibility analysis at Deloitte Consulting. He has assisted large organizations like Best Buy and Bank of America with the adoption of emerging technologies by applying systematic methods to resolve complex design contradictions. At netrii, David applies his "Matrix Morphology" methodology to help large and small businesses bridge the gap between technical potential and human-centric application, focusing on ways that systematic innovation can drive product and service value in the age of generative intelligence. **Credibility Markers**: - Founder and CEO of Adaptive Avenue (patented personalization platform) - Founder and Principal at Innovation Radiation - training / coaching / consulting on systematic innovation - Technology analyst at Stanford Research Institute (SRI) - Senior consultant at Deloitte Consulting - Named inventor on four U.S. patents in Web architecture and user experience - Endorsed by Doug Engelbart for human-centric design **Philosophy**: "Innovation isn't just about new tools; it's about resolving the contradictions in our current systems to create more fluid, human-centric experiences. We must move from quantitative data and information to qualitative knowledge and wisdom." --- ### Megan C. Starkey **Title**: Principal Advisor & Enterprise AI Capability Builder **Profile**: https://www.netrii.com/experts/megan-starkey **Website**: https://rbdco.ai Megan Starkey is an enterprise AI transformation executive and growth leader who builds the complete architecture required to operationalize AI as a core business capability — not just the technology, but the leadership, operating models, and governance that determine whether AI initiatives produce results or stall. A "bilingual" executive fluent in both technology and business, she operates as the bridge between engineering and the boardroom, with $1B in documented impact across 25+ engagements spanning financial services, CPG, industrial manufacturing, SaaS, and technology. She has led organizations through every major technology wave of the past two decades, from the early internet and digital advertising, through big data and cloud, to artificial intelligence. Today she leads RBD Co., an enterprise AI advisory where a bench of 10 senior consultants delivers AI enablement, use case evaluation, operational integration, and organizational change at scale. Her core premise is that AI is an organizational evolution, not a technology deployment — and that building capability across four dimensions (technology, people, operations, and governance) is what separates AI programs that scale from those that don't. At a $4 billion global insurer, her team increased leadership confidence from 19% to 89%, expanded campaign ideation from 2 to 24 per year, accelerated governance from 6 months to 48 hours, and achieved 3x workforce productivity. Previously, as Acting Director at Thrivent ($198B AUM), she directed a $24 million paid media budget and delivered 138% year-over-year revenue growth. Her proprietary frameworks include the Starkey Model™ for use case prioritization (40+ Fortune 1000 evaluations), the Intelligence Method (four-band transformation architecture), and the Dynamic Weighting Engine (patent pending), a NIST SP 1270-compliant data unification technology. **Credibility Markers**: - Founder & CEO, RBD Co. — Enterprise AI advisory serving financial services and growth-stage organizations - Creator of the Starkey Model™ — 40+ Fortune 1000 evaluations - Creator of the Intelligence Method — four-band transformation architecture for enterprise AI capability - Dynamic Weighting Engine (patent pending) — NIST SP 1270-compliant data unification technology - $1B in documented impact across Target, General Mills, Thrivent, IBM, UPS, Chase, and others - Author, The Intelligence Organization (Q1 2026) and AI for Marketing Leaders (Springer, in review) - Publisher of AI:Unlocks and CMO/AI — Fortune 100 readership (3M, UnitedHealth, Best Buy, Target, US Bank, Medtronic, Wells Fargo, Ecolab) - Harvard Business School, Executive Education — Organizational Leadership - AI Circle Founding Member (OpenAI, Meta, Anthropic, Nvidia) **Philosophy**: "AI is an organizational evolution, not a technology deployment. Building capability across technology, people, operations, and governance is what separates AI programs that scale from those that don't." --- ### Dan McCreary **Title**: Advisory Circle & AI Education Visionary **Profile**: https://www.netrii.com/experts/dan-mccreary **Website**: https://dmccreary.github.io/dmccreary Dan McCreary is a pioneering force in AI-powered education and one of the world's leading practitioners of Claude Code Skills for building intelligent textbooks. He is revolutionizing how teaching is done and learning is accomplished by helping educational organizations cut the costs of building free, interactive intelligent textbooks by 100x. As a GenAI strategy consultant and senior data architect, Dan leverages AI and Claude Code Skills to build standards-compliant, reusable MicroSims—interactive simulations that transform static textbooks into dynamic learning experiences. His mission is to democratize education globally by making high-quality, interactive educational content accessible to all. Dan has created over 64 intelligent textbook projects spanning subjects from geometry and calculus to circuits, data science, and machine learning—each featuring interactive MicroSims, detailed learning graphs, and comprehensive glossaries. With over four decades of experience in AI and knowledge representation, Dan previously served as Head of Artificial Intelligence at TigerGraph and Distinguished Engineer at Optum (UnitedHealth Group), where he helped build one of the world's largest healthcare knowledge graphs. His storied career includes foundational work at Bell Labs with the creators of Unix and at NeXT Computer with Steve Jobs. A systems thinker at heart, Dan is passionate about STEM education, mentoring students through CoderDojo Twin Cities, and co-founding initiatives like the AI Racing League. He believes that effective education must pair precise world models using scale-out distributed native knowledge graphs with the power of generative AI. **Credibility Markers**: - Pioneer in Intelligent Textbooks & Claude Code Skills - Former Head of AI at TigerGraph - Distinguished Engineer at Optum (UnitedHealth Group) - Built the world's largest healthcare knowledge graph at Optum - Established the Generative AI Center of Excellence at Optum - Founded the Optum AI Racing League (250+ participants) - Early Engineer at Bell Labs and NeXT Computer - Co-author of "Making Sense of NoSQL" (Manning Publications) - MS in EECS from University of Minnesota & MBA from University of St. Thomas **Philosophy**: "Effective education must pair precise world models using knowledge graphs with the power of generative AI to make learning accessible, affordable, and deeply interactive." --- ### Sharat Batra, PhD **Title**: Venture Lead — Storage, Digital Twins & Quantum Advisory **Profile**: https://www.netrii.com/experts/sharat-batra **Website**: https://linkedin.com/in/sharatbatra Sharat Batra is a senior technologist and systems architect with over four decades of experience designing, scaling, and delivering complex hardware and data-driven systems in high-reliability environments. His career spans foundational work in magnetic and semiconductor materials, large-scale data storage architectures, AI-driven manufacturing optimization, and emerging quantum computing systems—bridging first-principles physics with real-world product execution. Sharat is widely recognized for his ability to translate deep technical research into manufacturable, field-ready technologies. At Western Digital and Seagate Technology, he led nanofabrication-intensive R&D and product programs that shaped industry roadmaps, including Shingled Magnetic Recording (SMR), Microwave-Assisted Magnetic Recording (MAMR), and Heat-Assisted Magnetic Recording (HAMR)—technologies that underpin today's AI-driven data infrastructure. His work has resulted in 50+ issued patents and trade secrets and 40+ refereed journal publications in magnetism, recording physics, and semiconductor growth. A defining theme of Sharat's work is the responsible application of AI and machine learning in physics-constrained systems. As NAND Product Program Manager, he applied ML-driven test optimization and predictive failure analysis to manufacturing, achieving over $30M in cost savings while improving yield and reliability. His approach emphasizes interpretability, robustness, and manufacturability—recognizing that ML in hardware systems must withstand process variation, material uncertainty, and regulatory constraints. In parallel with his industry leadership, Sharat is deeply engaged in quantum computing systems awareness and benchmarking. Through his entrepreneurial venture, Coherent Quantum, he advises organizations on quantum readiness, optimization methods, and the integration challenges that lie between laboratory demonstrations and deployable systems. His interests include physics-informed neural networks (PINNs) and quantum-adjacent optimization techniques that combine physical insight with data-driven performance. Sharat currently serves as an Adjunct Professor in Electrical and Computer Engineering at the University of Minnesota, where he teaches circuits, semiconductor materials, and senior design. His teaching philosophy mirrors his industry practice: systems thinking, ethical engineering, and an end-to-end understanding of how technologies move from concept to product. He is particularly committed to mentoring students from underrepresented backgrounds and preparing engineers to work across hardware, AI, and emerging quantum technologies. **Credibility Markers**: - Senior Technologist at Western Digital & Seagate Technology — led R&D shaping industry storage roadmaps (SMR, MAMR, HAMR) - 50+ issued patents and trade secrets in magnetic recording, semiconductor growth, and data storage - 40+ refereed journal publications in magnetism, recording physics, and semiconductor materials - NAND Product Program Manager — applied ML-driven optimization achieving $30M+ in cost savings - Founder of Coherent Quantum — advising on quantum readiness and optimization methods - Adjunct Professor, Electrical & Computer Engineering, University of Minnesota - PhD in Physics/Engineering with four decades of systems architecture experience **Philosophy**: "Meaningful innovation occurs when physics, algorithms, manufacturing, and human judgment are designed together. The goal is to build technologies that are not only advanced, but also scalable, reliable, and aligned with real societal needs—from AI infrastructure to future quantum systems." --- ### Susan (Sue) Hamre **Title**: Advisory Circle & Enterprise Sales Strategist **Profile**: https://www.netrii.com/experts/sue-hamre **Website**: https://www.linkedin.com/in/susanhamre Sue Hamre is a strategic sales leader and enterprise advisor who spent 27 years at Gartner building C-level relationships across Healthcare and Life Sciences — one of the most complex and regulated sectors in enterprise technology. Trained originally as an architect at the University of Pretoria, she brings a rare visual and structural lens to problem-solving: identifying the root cause of a client's challenge rather than addressing symptoms, and designing comprehensive solutions that align technology investment to business outcomes. At Gartner, Sue progressed from Account Executive through Client Director to Sales Manager of Global Enterprise accounts, leading a tenured team responsible for strategic Healthcare and Life Sciences clients. Her work centered on building cross-functional C-suite relationships — not just within IT, but across business units — and demonstrating how research and advisory services could drive revenue, reduce risk, and shorten decision cycles. Before Gartner, she came through META Group (acquired by Gartner in 2005), and earlier led international sales at ColorSpan where she built an e-commerce platform and managed a multilingual sales team from the ground up. Today, Sue is an independent advisor focused on AI-powered value creation. Her philosophy centers on "meta-knowledge" — moving beyond domain expertise to understand how knowledge itself is structured and applied across organizations. She advocates for "autonomation": automating the mechanical aspects of business while preserving the human judgment and intuition that drive consequential decisions. She uses a fleet of AI agents and tools like NotebookLM to deliver strategic insights in hours that previously took weeks — what she calls a "two-year advantage." Sue is also a builder of curated high-talent networks — what she terms "private tribes" — where elite experts share opinions and data in exclusive, high-value environments. Her career arc, from CAD draughtsperson in Pretoria to enterprise sales leader at one of the world's most influential research firms, reflects a consistent thread: the craft of turning complex information into decisions that move organizations forward. **Credibility Markers**: - 27 years at Gartner — Sales Manager, Global Enterprises, Healthcare & Life Sciences - META Group Account Executive (acquired by Gartner, 1999–2005) - Director of Sales, ColorSpan — built international e-commerce platform and multilingual sales team - 300% sales growth at The Vector Group (South Africa) — top-performing sales person - University of Pretoria — ND Architecture (1984–1986) - Expert in Challenger and Value Selling methodologies - Practitioner of AI-native operations: fleet of AI agents, NotebookLM, componentized strategy systems **Philosophy**: "Success in the modern era requires moving beyond traditional domain expertise toward meta-knowledge — understanding how knowledge is structured, applied, and shared. AI handles the mechanical. Human wisdom navigates the consequences." --- ## Wisdom Library ### AI-Liquid Learning **Format**: RESEARCH **Author**: Rick Tanler **Tags**: AI Strategy, Liquid Intelligence, Capability Framework, Continuous Learning, AI Operating Model, Learning **URL**: https://www.netrii.com/wisdom/ai-liquid-learning A category framework defining the eight AI capabilities — organized into Foundation, Interaction, and Trust layers — that separate a Liquid Learning product from a chatbot. Knowledge, like water, must simultaneously grow and flow — adapting to the shape of every challenge, filling every gap, and never truly settling. That is the philosophy of Liquid Learning, and for the first time in history, AI gives us the infrastructure to make it possible at scale. The world today changes faster than any fixed learning curriculum can accommodate. The greatest competitive advantage an organization can hold is not what it knows today — it is how quickly, how deeply, and how continuously it can learn tomorrow. The analogy to Business Intelligence is instructive. BI was not defined by any single product but by a common set of platform capabilities — data connectivity, dimensional modeling, visualization, and query — that every product in the market had to provide. Domain expertise and user experience differentiated competitors; the capability layer defined the category. AI-Liquid Learning follows the same architecture. The eight capabilities in this brief are the category definition: Learner Modeling, Memory & Continuity, Adaptive Content Delivery, Conversational Depth on Demand, Knowledge Synthesis, Safe Domain Handling, Voice & Tone Matching, and Practice & Reflection Generation. For executives, Liquid Learning is not merely an HR initiative. It is a strategic architecture decision. The organizations that will lead their industries in five years are the ones building, right now, the systems and cultures that make continuous knowledge growth and dissemination an operating standard. Knowledge has always been power. But in the age of AI, it is not the knowledge you have accumulated that will define your organization's future — it is the speed and continuity with which you keep learning. Liquid Learning is not a program. It is a posture. --- ### Physics-Informed Neural Networks for Projectile Trajectory Prediction Under Quadratic Aerodynamic Drag **Format**: RESEARCH **Author**: Sharat Batra, PhD **Tags**: Physics-Informed Neural Networks, PINN, Scientific Machine Learning, AI Strategy, Manufacturing, Semiconductors **URL**: https://www.netrii.com/wisdom/pinns-projectile-trajectory A technical demonstration that physics-informed neural networks (PINNs) — which embed Newton's second law directly into the loss function — outperform conventional data-driven neural networks for predicting projectile trajectories subject to velocity-dependent quadratic aerodynamic drag. This work was inspired by a senior design project in which students applied neural networks to model the kinetics of emergent colloidal aggregation phenomena in particle-laden fluids — demonstrating that physics-aware learning generalizes across domains far beyond ballistics. Machine learning models trained solely on data interpolate well but extrapolate poorly. This brief, by Sharat Batra (University of Minnesota ECE), extends physics-informed neural networks (PINNs) from the well-studied 1D damped oscillator to a nonlinear, coupled, two-dimensional system: a projectile under velocity-dependent quadratic aerodynamic drag — a problem with no closed-form analytical solution. Using only 8 noisy position measurements from the first 25% of the flight (the ascending phase), the PINN — which encodes Newton's second law and the drag force directly into the loss function via automatic differentiation — correctly predicts the complete trajectory including the asymmetric descent and ground impact. The conventional NN of identical architecture fails to predict the apex at all, extrapolating along a monotonically increasing curve. First, the physics loss provides a powerful inductive bias that constrains the output to the physically admissible manifold. By requiring consistency with the governing differential equations at collocation points distributed across the full temporal domain, the PINN extrapolates accurately into regions completely devoid of training data. Second, the approach is inherently noise-robust. The physics residual penalizes trajectories that violate Newton's laws even when those trajectories would more closely fit noisy observations, preserving accuracy under noisy real-world measurement conditions. Third, no closed-form solution is required. The projectile–drag system has no analytical solution, yet the PINN learns the dynamics directly from the differential equations via automatic differentiation. This makes the method broadly applicable to many domains including manufacturing, semiconductor processing, and computational physics. Together, these properties position PINNs as a practical tool for any domain where governing equations are known but data is sparse, noisy, or expensive to collect. --- ### The Invisible Architecture **Format**: PDF **Author**: Arun Batchu **Tags**: Leadership, Organizational Design, Network Science, Innovation **URL**: https://www.netrii.com/wisdom/invisible-architecture How natural connectors, glue people, and idea brokers power organizational intelligence. In a petrochemical company with billions in fixed-asset costs, a single cross-functional meeting—one that nearly never happened because the right people didn't know each other existed—unlocked a dormant solution worth an estimated $47 million. No restructuring. No new enterprise software. The company simply made visible the social architecture that was already there. Research from network science, behavioral psychology, neuroscience, and management studies converges on a truth most organizations have yet to act on: value is not created where the org chart says it is. This research brief explores the 3% of people who drive 35% of value, the structural holes where innovation lives, and the behavioral science behind the "glue players" who hold complex organizations together. --- ### Beyond Efficiency: Designing Collective Intelligence in the AI Era **Format**: PDF **Author**: Arun Batchu **Tags**: Leadership, Organizational Design, AI Strategy, Collective Intelligence **URL**: https://www.netrii.com/wisdom/designing-collective-intelligence Why the next competitive advantage isn't artificial intelligence — it's shared wisdom. A practical framework for engineering organizations that think collectively. The prevailing AI conversation focuses on individual efficiency — speeding up tasks like coding, email, and automation. This brief argues that the true competitive advantage of the next decade won't come from individual speed, but from your organization's capacity for collective thinking. Drawing on pioneering research from Alex "Sandy" Pentland of MIT Media Lab (author of Shared Wisdom and Honest Signals), this brief shows how leaders can apply the principles of Social Physics to engineer organizations that don't just process data, but cultivate profound collective wisdom. Covers three critical organizational networks — Exploration (bridging silos), Engagement (optimizing interaction quality), and Storytelling (preserving institutional knowledge) — with specific AI tools and rituals for each. Includes a First 30 Days action plan for immediate implementation. --- ### The Core Theory of Useful Knowledge **Format**: PDF **Author**: Arun Batchu **Tags**: Economics, Innovation, Strategy, Knowledge Management **URL**: https://www.netrii.com/wisdom/core-theory-useful-knowledge Understand why some nations and organizations thrive while others stagnate—through the lens of Nobel Prize-winning economic theory. Drawing on Joel Mokyr's Nobel Prize-winning research, this guide explains how two types of knowledge—propositional ("knowing why") and prescriptive ("knowing how")—create the feedback loops that drive sustained innovation and economic growth. You'll learn why the Industrial Revolution wasn't just about clever inventions, but a fundamental transformation in how societies create, share, and apply knowledge. The same principles that enabled 18th-century breakthroughs now explain why Silicon Valley succeeds, why some nations remain trapped in middle-income status, and how to build innovation ecosystems. Includes practical frameworks for applying these insights to modern challenges in AI, biotechnology, and organizational design—with actionable guidance for policymakers and business leaders. --- ### TOC Bike Shop Simulator **Format**: SIMULATOR **Author**: Arun Batchu **Tags**: Theory of Constraints, Operations, Systems Thinking, Simulation **URL**: https://www.netrii.com/wisdom/bike-simulator An interactive Theory of Constraints experience — see bottlenecks, WIP, throughput, and the Five Focusing Steps in motion. Turn abstract ideas into a visible flow of cause, effect, and constraint. This interactive simulator lets you run a bike shop production line and watch what happens when one station can't keep up. Apply the Theory of Constraints Five Focusing Steps: Identify the bottleneck, Exploit it, Subordinate everything else, Elevate, and Repeat. The simulator includes a built-in AI assistant to guide your exploration. --- ### TOC Software Delivery Simulator **Format**: SIMULATOR **Author**: Arun Batchu **Tags**: Theory of Constraints, Software Development, Engineering Ops, Simulation **URL**: https://www.netrii.com/wisdom/sdlc-simulator Apply Theory of Constraints to software development — see how handoffs, queues, reviews, and context switching affect delivery velocity. The bottleneck in software delivery is rarely coding speed. This simulator makes visible the constraints that actually slow teams down: handoffs between stages, review queues, context switching, and multitasking overhead. Run experiments to see how different policies affect throughput and cycle time. Pair the interactive experience with guided chat and practical explanation of Theory of Constraints applied to engineering operations. --- ### Mastering Technical Communication **Format**: TEXTBOOK **Author**: Arun Batchu **Tags**: Communication, Engineering Education, Technical Writing, Presentations **URL**: https://www.netrii.com/wisdom/technical-communication An interactive intelligent textbook on clarity, impact, and influence for engineers — featuring 15 chapters, 275 concepts, and hands-on MicroSims. Technical skills land a job, but communication skills drive career advancement. This intelligent textbook equips engineers and technical professionals with practical, proven frameworks for communicating ideas with clarity, impact, and influence. Covers nine named frameworks including the Feynman Technique, Minto's Pyramid Principle, MECE, Smart Brevity, the Dilution Effect, Tufte's 4S visualization model, Klein's storytelling model, and Duhigg's Supercommunicators. Each framework is taught with real engineering examples, exercises, and interactive simulations. Built with a 275-concept learning graph, 150 Bloom's Taxonomy-aligned quiz questions, a 275-term glossary, and five interactive MicroSims — including a Pyramid Builder, Dilution Effect demo, Audience Analyzer, and Presentation Timer. Designed for ECE/CS undergraduates and early-career engineers. --- ### The Full Stack of Intelligence: From HBM to HDD **Format**: RESEARCH **Author**: Sharat Batra, PhD **Tags**: AI Strategy, Infrastructure, Hardware, GPU, Storage, DDR5, HBM **URL**: https://www.netrii.com/wisdom/ai-infrastructure-full-stack Why every tier of the AI hardware hierarchy — GPU, CPU, HBM, DDR5, NVMe, SSD, and HDD — is now supply-constrained, cost-volatile, and mission-critical. An investor technical brief on seven-tier architecture. Effective AI infrastructure requires understanding the interdependence and distinct role of seven hardware tiers — GPU, CPU, HBM, DDR5 DRAM, NVMe SSD, SATA/QLC SSD, and HDD — yet most organizations treat these as independent procurement decisions. As of 2026, each tier is simultaneously supply-constrained and price-volatile due to AI-driven demand, compounding the cost of misalignment across the entire stack. Organizations that replace ad-hoc tier procurement with software-managed tiered architectures — deliberately matching each hardware layer to its optimal workload role and treating DDR5, HBM, NVMe, and HDD as an integrated system — consistently achieve 4–6× TCO reduction, 90%+ GPU utilization, and procurement resilience across a supply environment that has never been tighter. This research brief covers the complete seven-tier hardware hierarchy, five integration challenges requiring active software management, software-managed tiered architecture with Ceph/Lustre/Spectrum Scale, and detailed use cases for both large-scale training and real-time inference serving — with documented outcome metrics and capital allocation frameworks. --- ### The Spinning Disk Strikes Back: Why HDDs Are the Hidden Infrastructure Bet **Format**: RESEARCH **Author**: Sharat Batra, PhD **Tags**: AI Strategy, Infrastructure, Storage, Hardware, HDD, SSD **URL**: https://www.netrii.com/wisdom/spinning-disk-strikes-back Why SSD-first AI storage architectures create systemic capital misallocation of $5–17M per 50PB deployment — and how workload-matched tiered storage anchored by next-generation HDDs delivers 67–70% TCO reduction while improving GPU utilization. As AI training datasets scale from petabytes to exabytes, the industry’s default bias toward SSD-first storage architectures is creating a systemic capital misallocation that inflates infrastructure costs by 6–8× without delivering commensurate performance gains for training workloads. Organizations that architect workload-matched, tiered storage — anchored by next-generation hard disk drives (Seagate Mozaic 4+ at 44TB and WD 40TB UltraSMR) — can recapture $4–17M per 50PB deployment and redirect that capital into GPU compute and talent. This investor intelligence report covers workload physics (why training access patterns favor spinning media), storage economics (the 6–8× cost gap through 2030), technology strategy (HAMR vs. UltraSMR at the 44TB/40TB threshold), financial scenario modeling, and the supply-constrained procurement landscape through 2028. --- ## Blog ### An Agent Now Costs About What an Offshore Hour Costs, and the Agent Keeps Getting Cheaper **Date**: September 18, 2026 **Author**: Arun Batchu & Claude (AI) **Tags**: ai-shoring, offshoring, ai-agents, economics, predictions **Reading Time**: 12 min **URL**: https://www.netrii.com/blog/ai-shoring For routine support, invoices and code tickets, an AI agent with a person checking it now costs about the same as offshore labor, or less. A simple model shows the threshold rate for each kind of work, why checking is most of the bill, and what happens after the lines cross. Think about the self-checkout lanes at a big grocery store. Six machines stand in a row, and one employee stands at a small podium watching all of them. Most of the time the employee does nothing you can see. Then a light turns red over lane four, because the scale didn't believe a bag of limes. The employee walks over, taps in a code, and walks back. That store used to pay six cashiers to run six lanes. Now it pays for six machines and one person, and that person's whole job is the red light. When the arrangement works, the store saves money and you get out faster. It doesn't always work. In March 2024 Dollar General [took self-checkout out of about 300 stores](https://www.cnn.com/2024/03/14/business/self-checkout-dollar-general) to cut its losses from theft and scanning mistakes. The machines were cheap, and what slipped past them wasn't. I've been thinking about those lanes because the same arrangement is arriving in a much bigger business, which is the routine software and back-office work that companies send offshore. The machine turns out to be the small part of the bill. The person at the podium is the large part. ## The claim For thirty years companies have sent routine work to India, the Philippines and elsewhere for one reason: an hour of labor costs less there. **For some of that work, an AI agent with a person checking it now costs about the same as the offshore hour, or less. Once the two costs cross, I don't think they cross back.** Offshore wages rise a few percent a year, and the agent's side of the bill keeps falling. The name going around for this is *AI shoring*: one more sourcing choice next to offshoring, nearshoring and onshoring. I built a calculator under that name in March and believed I'd coined it. I hadn't. Samuel Sutcliffe [used it in January 2025](https://www.linkedin.com/pulse/we-entering-era-ai-shoring-samuel-sutcliffe-85hme) for banking process teams. Mark O'Neill at Gartner [described it in April 2025](https://www.linkedin.com/posts/markwoneill_ai-shoring-is-the-new-trend-its-actually-activity-7314411186488266752-WD4W) as one senior developer with AI tools in place of an offshore team, and Gartner published his note on it this January. A New York company has a US trademark application pending on the phrase. HFS Research calls the same shift *services-as-software*, Reply calls it *silicon shoring*, and [LeadDev](https://leaddev.com/ai/agent-shoring-end-offshoring) calls it *agent-shoring*. So the name belongs to other people. What I haven't seen any of them publish is the arithmetic, with the person who checks the agent counted in. This post is the arithmetic. > **Key point:** Compare an agent with an offshore hire per finished unit of work, and count the person who checks the agent. On that basis support chat and invoices have already crossed, and routine code tickets are crossing now. ## Count the finished unit, not the hour An hourly rate tells you very little, because what you're buying is a resolved chat, a processed invoice or a fixed bug. So the model prices one finished unit on each side. The offshore hire needs three numbers: the rate the vendor bills per hour, how many units a person finishes in an hour, and what you spend managing the vendor. ISG [puts that last one](https://isg-one.com/docs/default-source/default-document-library/47-governance-plugging-value-leak_interactive.pdf) at 8 percent of the contract when it's done well and 15 percent commonly. I use 15. The agent needs three numbers too: what the machine costs per attempt, what it costs for a person to check that attempt, and what share of attempts succeed. The attempts that fail go back to a person, so they cost you the human price on top. ```text human cost per unit C_h = (rate / units per hour) x (1 + overhead) agent cost per unit C_a = machine + checking + (1 - success rate) x C_h the agent wins when machine + checking < success rate x C_h threshold rate w* = units per hour x (machine + checking) / (success rate x (1 + overhead)) payback volume N* = setup cost / (success rate x C_h - machine - checking) ``` The threshold rate is the number to watch. If your vendor bills more than that per hour, the offshore hour loses on cost. The last line explains why small jobs stay with people: an agent has a setup cost, and it takes volume to earn that back. ## Three kinds of work, three different answers | Work | Offshore, per unit | Agent, per unit | Threshold rate | |---|---|---|---| | Support chat | $2.68 | $1.40 to $1.84 | $3.87 an hour | | Invoice | $3.25 | $0.77 | pennies | | Routine code ticket | $115 | $82 to $128 | $16 to $31 an hour | **Support chat has crossed.** Chat support from India or the Philippines bills at about $10.50 an hour, by the [rethinkCX cost index](https://www.rethinkcx.com/resources/bpo-cost-index/philippines) for May 2026. At 11 minutes a chat, which is what Klarna's human agents averaged, and ordinary occupancy, a person finishes 4.5 chats an hour. That is $2.68 a chat with overhead. Intercom's Fin [lists $0.99](https://fin.ai/pricing) per resolved chat and charges nothing when it fails. Intercom says 76 percent get resolved, and third parties report nearer 50. Either way the threshold works out to $3.87 an hour. The worker takes home roughly 30 percent of the billed rate, or $2.40 to $5.20 an hour. **The agent's list price already matches the worker's pay, never mind the vendor's rate.** And $0.99 is a price. Anthropic's own worked example puts the model cost of a support ticket at about a third of a cent. **Invoices have crossed, if you have the volume.** Outsourced invoice processing sells for $1.50 to $5.00 an invoice, by vendors' own figures. AWS [charges a cent a page](https://aws.amazon.com/textract/pricing/) to read an expense document, and a language model adds a fraction of a cent. About 23 percent of invoices are exceptions that need a person. That comes to $0.77 against $3.25. The machine's share is two cents, and the rest is people handling exceptions. With an $18,000-a-year tool, payback comes at about 7,300 invoices a year. Below that, keep the people. **Routine code tickets are crossing now.** This one rests on assumptions, so here they are: a junior offshore developer at $25 an hour, and four hours for a routine ticket, which makes $115 with overhead. Vendor rate guides put junior developers in Asia at $24 to $31. The agent costs about $5 an attempt; published figures run from $1 to $13. A senior engineer spends 30 minutes checking each attempt, and at $114 an hour that's $57. Independent studies find [43 to 83 percent](https://arxiv.org/html/2601.15195) of agent pull requests get merged, depending on the tool. The answer is a tie: $115 for the person, and $82 to $128 for the agent. Move the sliders and put in your own numbers. ## Most of the agent's bill is the person at the podium Look at the code ticket again. The machine is $5 and the checking is $57. **More than ninety percent of what each attempt costs is the senior person who reviews it.** Token prices could fall to zero tomorrow and the ticket would cost almost the same. The field data says the same thing. Faros AI [found](https://www.faros.ai/ai-productivity-paradox) that teams using AI merged 98 percent more pull requests and spent 91 percent longer reviewing them. In a [2026 study](https://arxiv.org/abs/2607.01904) of 802 developers whose company told them to double their output, they did double it. Each reviewer's load doubled too, and automated review had to overtake human review before it held together. Goldratt would recognize this. Every system has one constraint. When agents make *doing* the work cheap, the constraint moves to *checking* it, and money spent anywhere else is wasted. (Our [bike shop simulator](/blog/bike-shop-toc-simulator) lets you watch a constraint move.) So the way to lower the threshold is to make checking cheaper: better tests, narrower tickets, automated review, and senior people who know the codebase. > **Key point:** If you want to know whether a piece of work is ready for agents, don't ask what the model costs. Ask how long it takes a person to know the output is right. ## After the lines cross The two sides then move in opposite directions. - The offshore hour creeps up. Indian IT salaries rise [6.6 to 7 percent a year](https://www.aon.com/apac/in-the-press/asia-newsroom/2026/aon-survey-projects-slight-uptick-in-salaries-in-india-2026), and the rupee has lost about 3 percent a year against the dollar, so in dollars the hour rises 3 to 4 percent a year. Right now clients are also [forcing one-time cuts of 25 to 30 percent](https://finance.yahoo.com/technology/ai/articles/ai-reshapes-indias-services-sector-230207347.html). That buys the rate card a few years. It doesn't change the slope. - The machine gets cheaper for a fixed job. The price of a fixed level of model capability falls [5 to 10 times a year](https://arxiv.org/abs/2511.23455). Frontier agent tasks haven't become cheaper, because newer agents burn far more tokens on harder problems. A routine ticket needs the same skill next year as this year, so the first number is the one that applies. - Success rates rise and checking shrinks. These two move the threshold most. If the merge rate for routine tickets goes from 60 to 85 percent over five years, and checking falls from 30 minutes to 10, the threshold drops from about $22 an hour to about $5. That is a scenario you can change in the chart above. I'm not offering it as a forecast. Other kinds of engineering have been through this. The mechanical cotton picker [broke even with hand labor around 1948](https://eh.net/encyclopedia/mechanical-cotton-picker/), when the picking wage passed $2.50 per hundred pounds. Machines picked almost none of the American crop that year and 96 percent of it twenty years later. William Nordhaus [found](https://www.cambridge.org/core/services/aop-cambridge-core/content/view/856EC5947A5857296D3328FA154BA3A3/S0022050707000058a.pdf/two-centuries-of-productivity-growth-in-computing.pdf) the cost of a computation fell 37 percent a year from 1945 to 1980. Once a machine matches the wage, the wage keeps rising slowly and the machine keeps getting cheaper fast. The same history carries a warning about reading this as the end of jobs. James Bessen [found](https://www.bu.edu/law/files/2017/04/autogro.pdf) that textile, steel and auto employment *grew* for decades alongside automation, because cheaper output sold in much larger volume. Jobs fell only when demand stopped growing. The US Bureau of Labor Statistics still projects developer jobs up about 16 percent from 2024 to 2034. ## Cheap versus checked The contradiction is this: agents make the work cheap, and cheap work that nobody checks gets expensive fast. Quimby's matrix shows four ways to answer it. Most of the industry is moving from **Q1, the Rate Card**, to **Q3, the Faster Pyramid**. It's the comfortable move, because the team and the contract stay the same. The savings go back to the client as price cuts, and the work is still sold by the hour. **Q2, the Empty Lane**, is the tempting mistake. It's the store that installs the machines and sends the attendant home. Klarna [said in 2024](https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/) that its assistant did the work of 700 outsourced agents, and [said in 2025](https://fortune.com/2025/05/09/klarna-ai-humans-return-on-investment/) that quality had dropped and it was hiring people again. **Q4, AI Shoring**, puts the agents on the volume and spends part of the savings on the podium. The clearest account I've found comes from PatientPoint's former CIO, who [told InformationWeek](https://www.informationweek.com/ai-innovations/outsourcing-contracts-weren-t-built-for-ai-cios-are-renegotiating-now) that 10 to 15 people with AI now do what 40 to 50 offshore developers, testers and analysts did. The small senior team is both of the model's hidden costs: they're the setup cost, and they're the checking cost. ## Where this argument is weak I'd rather you hear the weak spots from me. - The productivity gain is smaller than the sales pitch. Careful studies put a senior team's gain on ordinary company code at 20 to 50 percent. Doubling is the best documented team result. METR's [2025 trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) found experienced developers 19 percent *slower* with AI while believing they were faster. "A team three to five times smaller" isn't supported yet. - Offshore firms use the same tools. They're cutting prices and they're still here. India's company-owned centers [grew to 2.36 million people](https://www.prnewswire.com/in/news-releases/india-s-gccs-are-increasingly-leading-the-ai-mandate-for-global-enterprises-driving-global-value-creation-nasscom--zinnov-report-302817463.html) this year. A lot of the work is changing owners without changing countries. - I can't name a large company that has said on the record it ended an offshore IT contract because of AI. The pressure shows up in prices and headcount. The top five Indian firms shrank by about 7,400 people in fiscal 2026 while revenue stayed roughly flat. - Forecasts of collapse have a bad record. In July 2023 Emad Mostaque [said](https://www.cnbc.com/2023/07/18/stability-ai-ceo-most-outsourced-coders-in-india-will-go-in-2-years.html) most outsourced Indian coders would be gone in two years. Nasscom counts 5.95 million people in the sector today. - The model leaves out the cost of a wrong answer. That cost is what sent Klarna back to hiring, and it's different for a password reset than for an insurance claim. - The podium needs people, and the routine work used to train them. Stanford's payroll study [finds](https://digitaleconomy.stanford.edu/app/uploads/2026/08/Canaries_August2026.pdf) employment of 22-to-25-year-olds in AI-exposed jobs down 19 percent in relative terms, mostly from hiring that never happened. ## Five predictions you can check I'll come back to these when the dates pass. 1. **By the end of 2027**, at least one of the large support-agent products lists a resolved conversation below $0.50. Today's list prices run $0.99 to $2.00, against a model cost of under a cent. 2. **By March 2028**, the five largest Indian IT firms together employ fewer people than they did in March 2026, on higher revenue. 3. **By the end of 2028**, most new contracts for first-line support and invoice processing are priced per finished unit. HFS found only 5 percent of customer-service buyers contracted that way in 2026. 4. **By the end of 2028**, independent studies find agents' pull requests for routine tickets merged 85 percent of the time or better, which puts the model's threshold for that work under $12 an hour. No offshore developer bills that little. 5. **In 2030**, India's technology sector still employs more than five million people. The work moves up and moves in-house. It doesn't vanish. ## What I'd do with this Go back to the lanes. The store that pulled its machines out didn't have a machine problem. It had too few people at the podium, watching too many lanes, with no good way to tell a mistake from a theft. If you buy offshore work, I'd start where the volume is high and checking is quick, which usually means support and documents before code. I'd put a senior person at the podium *before* anyone's contract is cut. I'd measure two numbers every month, the share of attempts that succeed and the minutes it takes to check one, because those two set the threshold. And I'd make sure you own the instructions and the tests your agents run on. They're your know-how written down for the first time, and a vendor who holds them holds you. The open question for us at Netrii is the last weak spot. **Where do the people at the podium come from, once the routine work that trained them is done by the machines they're watching?** Whoever works that out will have the scarce thing, because everyone will have the agents. --- *This post comes from a research session in the [netrii Wisdom Library](https://netrii-wisdom-refinery.vercel.app/sessions/ai-shoring), [AI Shoring, 2026-09-18](https://netrii-wisdom-refinery.vercel.app/sessions/ai-shoring), which holds the full term history, the sources, and the inputs that are assumptions. The small senior team is the subject of [The Business Engineer](/blog/the-business-engineer).* --- ### Agents Will Let Tiny Teams Engineer Whole Businesses, Except for the Slow Parts **Date**: September 18, 2026 **Author**: Arun Batchu & Claude (AI) **Tags**: business-engineering, ai-agents, engineering-method, constraints, strategy **Reading Time**: 8 min **URL**: https://www.netrii.com/blog/the-business-engineer Product engineering merged building with deciding what to build. Agents will merge in the rest of the business, so one person or a small team can run all of it. Building speeds up, but trust doesn't, so the teams that win will start where trust already lives. Think about a food truck at lunchtime in any downtown. Two people work inside it. One of them cooks. The other takes orders on a tablet, remembers the regulars' names, and answers messages on the truck's Instagram between customers. Before the lunch rush, one of them bought the ingredients, and one of them renewed the health permit last spring. Between the two of them, they run a whole business: the product, the operations, the marketing, the money and the paperwork. Nobody calls them engineers. Now picture a second truck parking across the street. It sells the same tacos for a dollar less. Its owners copied the menu in a week, and they could have copied the Instagram account in an afternoon. They can't copy the line of people waiting at the first truck. That line took years to form. I've been thinking about both trucks since I made a prediction about where software work is going. I think it's right, and the second truck shows where it breaks. ## The prediction Software engineering plus product management produced product engineering. People who write the code also decide what to build and why, and the best product teams stopped handing work across that line a long time ago. **With language models and agents, I think the role will consolidate again, into business engineering.** A business engineer is a person, or a very small team of smart people, who designs, builds and maintains an entire business. AI does the routine work in every function. They'll build products that compete with today's companies, and they'll start new businesses at the speed we now build products. The food truck crew is already a two-person business engineering team, for a small business. My claim is that agents will let that same small team run a much bigger one. > **Key point:** Product engineering merged the people who build with the people who decide what to build. Business engineering adds operations, finance, marketing and support, because agents can now do the routine work in each of them. ## Why "engineering" is the right word Billy Vaughn Koen spent a career asking what engineers actually do. In his 1985 monograph for the American Society for Engineering Education, he defined the engineering method as "the use of engineering heuristics to cause the best change in a poorly understood situation within the available resources." A heuristic, for Koen, is a rule of thumb. It helps, it can't be proven, and it can fail. That definition describes starting a company better than it describes building a bridge. A founder wants to change something, wants the best change available, understands the situation only partly, and has limited money and time. Koen noticed this himself. He asked what human hasn't been in that position, and he concluded, "To be human is to be an engineer." Economics points the same way. Ronald Coase argued in 1937 that firms exist because coordinating work inside a company can be cheaper than contracting for every piece of it in the market. A firm grows until coordinating one more task inside costs as much as buying it outside. **Agents change that math. They do much of the work that used to take more people. They also make it cheaper to buy the rest from outside.** So a company needs fewer people to do the same job, and a tiny team can compete with a much bigger one. ## Where the prediction breaks The prediction has a weak spot. Building gets faster. A business doesn't get faster at the same rate, because much of a business was never about building. Robin Hogarth split the places where people learn into two kinds. In a *kind* environment, feedback comes fast and clear, and experience makes you better. In a *wicked* one, feedback is slow, late or misleading, and experience can teach you the wrong lesson. Daniel Kahneman and Gary Klein reached the same place in 2009 from opposite starting points. Intuition earns trust only where the environment is regular enough to learn and the feedback is quick and clear. Building a product is usually a kind problem. The code compiles or it doesn't, and the test passes or fails. Users click or they leave. Running a business is a wicked problem. Its feedback comes from customers, markets, regulators and time, and none of those speed up because your build did. **You can ship a competitor in a week, but you can't earn a market's trust in a week.** Goldratt explains what happens next. Every system has one constraint, and effort spent anywhere else is waste. (Our [bike shop simulator](/blog/bike-shop-toc-simulator) lets you watch a constraint move.) When agents make building cheap, building stops being the constraint, and the constraint moves to whatever doesn't speed up: - Distribution and attention. Customers have to hear about you, and they are already hearing about everyone else. - Trust and relationships. People buy from people they know, and knowing takes time. - Capital, licenses and liability. Banks, regulators and insurers move at their own pace. - Anything with atoms in it. Trucks, kitchens, warehouses and shipping don't compile. That is the second truck's mistake. It treated the menu as the moat, when the moat was the line. ## Speed versus trust The contradiction looks like this: agents give you speed, and customers give you trust, and trust takes time you don't have. Quimby's matrix shows four ways to answer it. Most of the new speed will go into **Q2, the Clone.** It's the obvious move, because agents make copying cheap, and it fails for the same reason the second truck fails. **Q3, the Old Line**, is safe for now, because its customers stay. Its risk comes from Q4. **Q4, the Business Engineer**, resolves the contradiction by starting where trust has already been earned. Picture a cook who leaves a popular restaurant to open a truck, and whose regulars walk two blocks to find the new window. The cook brings the line along instead of earning a new one. Agents now let that person build the rest of the business around the line faster than anyone could before. > **Key point:** The business engineer who wins builds at agent speed and starts inside relationships the team already holds. The human hours go to the slow things, because those are what can't be copied. ## Two things the speed hides **Maintenance.** The prediction says design, build *and maintain*, and maintenance is the verb most likely to be dropped. Guru Madhavan, in *Wicked Problems*, argues that efficiency without maintenance and resilience breaks. Every night the food truck crew cleans the grill and fixes the generator before it fails. A business built in a month by agents still needs someone to notice when a supplier changes terms, a payment integration drifts, or a customer promise quietly stops being kept. **Accountability.** Koen also wrote a Rule of Judgment: judge an engineer against the best practice of the time the design was made. That rule assumes there is an engineer to judge. When two people and their agents run payroll, hold customer data and make promises, someone answers for what happens. Law and insurance will decide how fast business engineering becomes an ordinary job, probably more than the tools will. ## This has been tried before Business engineering isn't a new phrase. In the early 1990s, Michael Hammer and James Champy's *Reengineering the Corporation* set out to redesign companies around their processes. In Switzerland, Hubert Österle's school at St. Gallen taught *business engineering* as the joint design of strategy, process and information systems. Hammer and Champy themselves offered what they called an "unscientific estimate" that 50 to 70 percent of reengineering efforts fell short of the dramatic results they aimed for. Those efforts treated the firm as a machine to redesign, and a firm is full of people and habits that don't change on schedule. The difference now is that agents can do the work, not just draw the new process. **What hasn't changed is that customers, partners and regulators are still people**, and they move at human speed. ## What I think happens next The business engineer is coming, and the direction of the prediction holds. The speed part holds only for the fast parts of a business. The people who do well will build products at software speed and build trust at human speed, and they'll know which part is which. Go back to the first truck. Its two owners are good at cooking and good at running a small business, but the thing nobody can copy is their judgment about what to change and when. They added a vegetarian taco because the regulars kept asking. They stayed off Saturdays because the downtown empties out. So the question I'd put to anyone who wants to be a business engineer is this: **is the scarce skill building the thing, or choosing which change is worth making?** Koen's answer, I think, would be choosing. His Rule of Engineering asks each engineer to do what they think represents best practice at the time they must decide. Everyone will have the agents. The judgment about what's best, and the relationships that make people trust it, are what stay scarce. The open research question for us at Netrii is what the rules of thumb of business engineering are. Product engineering has decades of them. Business engineering, in Koen's terms, has a very small state of the art, because its feedback is slow. The first people to collect and share those rules of thumb will help everyone else build faster, which is how useful knowledge has always spread. --- *This post comes from a conversation in the [netrii Wisdom Library](https://netrii-wisdom-refinery.vercel.app/sessions/2026-09-18-business-engineer). Arun Batchu put forward the prediction and tested it against the strongest counterarguments, on [2026-09-18](https://netrii-wisdom-refinery.vercel.app/sessions/2026-09-18-business-engineer). The engineering-method background is in the [Engineering Method](https://netrii-wisdom-refinery.vercel.app/sessions/engineering-method) session.* --- ### Stop Training. Build a Learning System. **Date**: May 2, 2026 **Author**: Rick Tanler **Tags**: ai-strategy, liquid-intelligence, learning, capability-framework, leadership **Reading Time**: 5 min **URL**: https://www.netrii.com/blog/stop-training-build-a-learning-system The half-life of a professional skill is now under five years. Annual training cycles cannot keep pace. The companies that lead in five years will be the ones that built a capability stack — not a course catalog. **Stop running training programs. Start building a learning system.** The half-life of a professional skill is now under five years and shrinking. Annual training cycles cannot keep pace. Classroom formats cannot personalize at scale. Static content libraries go stale the moment they are published. And yet most organizations are still doing what they have always done — scheduling courses, issuing certificates, and quietly waiting for the next intervention. That model served an era of slow-moving industries and stable job descriptions. It no longer does. > **Key point:** The greatest competitive advantage an organization can hold today is not what it knows. It is how quickly, how deeply, and how continuously it can learn. That is a different operating posture, not a bigger budget for the same posture. ## I have seen this movie before In the early 1990s I founded Information Advantage and built one of the first business intelligence companies. Back then, the conversation about BI was confused for years. Vendors pitched dashboards. Analysts pitched reports. Executives bought tools that did one slice of the job and called the result a "BI strategy." It took the better part of a decade for the industry to converge on what BI actually was — not a product, but a *capability stack*. Data connectivity. Dimensional modeling. Visualization. Query. Every serious product had to provide all of it. The capability stack defined the category. Domain expertise and user experience differentiated the competitors. AI-era learning is in the same confused moment now. There are training platforms. There are chatbots. There are LMSs with AI bolted on. Each one is selling a slice. And each one, on its own, is to learning what a single dashboard was to BI: a feature, not a system. ## The eight capabilities that define a learning system What separates a real Liquid Learning product from a chatbot dressed up in a training UI is whether it deploys all eight of these capabilities, in concert, across a knowledge domain. These are not features to pick from. They are the category definition. - **Learner Modeling.** Reads context. Infers knowledge level from how the question is asked. Tracks what has been covered, what caused confusion, what the learner cares about. Adjusts register without being asked. - **Memory & Continuity.** A product that forgets the learner between sessions is a chatbot, not a product. Persistent memory is the infrastructure distinction. - **Adaptive Content Delivery.** Decomposes complex concepts into layers and serves the layer that fits this learner right now. Holds deeper material in reserve until readiness signals arrive. - **Conversational Depth on Demand.** Goes deeper on the thing that caught the learner's attention — not the next chapter, but this sentence, right now — without losing the thread across the broader arc. - **Knowledge Synthesis.** Pulls together what is known from multiple angles and presents it as coherent understanding, not a bibliography. The functional difference between retrieval and teaching. - **Safe Domain Handling.** Knows when to inform, when to defer to a professional, and when to add nuance rather than a conclusion. A prerequisite for any high-stakes deployment. - **Voice & Tone Matching.** Holds a consistent brand voice across thousands of interactions while still responding naturally to each individual learner. - **Practice & Reflection Generation.** Generates calibrated questions, scenarios, and prompts based on what this particular learner just encountered. Converts exposure into retained knowledge. Three layers — Foundation, Interaction, Trust — and the eight capabilities live inside them. Drop one capability and the system collapses to a feature. Deploy all eight and you have a Liquid Learning product. Deploy them across a knowledge domain that matters to your business and you have an operating advantage. ## What this means for executives buying right now If you are evaluating an AI-driven learning vendor, here is the operator question to ask: *Which of the eight capabilities do you provide, and which do you assume someone else provides?* Most pitches today will quietly answer "two or three." That is fine — but you are then building the rest of the stack yourself, and the integration burden is on you. If you are building internally, the same question applies in reverse. The capabilities are not optional. Memory & Continuity without Learner Modeling produces a system that remembers but does not understand. Knowledge Synthesis without Safe Domain Handling produces a system that teaches confidently in domains where it should be deferring. The stack is a stack because every layer relies on the one below it. > **Key point:** The companies that will lead their industries in five years are the ones building, right now, the systems and cultures that make continuous knowledge growth and dissemination an operating standard — not a periodic training event. ## Liquid Learning is a posture Knowledge has always been power. But in the age of AI, it is not the knowledge you have accumulated that defines your organization's future. It is the speed and continuity with which you keep learning. That is not a program you can purchase, run for a quarter, and report on. It is a posture — an operating standard you build into how the business actually works. The infrastructure to make this real exists today. The capability stack that defines the category is now visible. The remaining question is whether your organization will build for it now, or wait to be told by a vendor what to buy in five years. If you waited on BI in 1995, you spent the rest of the decade catching up. Do not wait on this one. --- *This post is a verdict-first companion to the full research brief. The brief lays out the AI-Liquid Learning Capability Framework in detail, with a layer-stack diagram and per-capability descriptions: [AI-Liquid Learning](/wisdom/ai-liquid-learning).* --- ### Notes on Physics-Informed Neural Networks: A Projectile Experiment **Date**: May 1, 2026 **Author**: Sharat Batra, PhD **Tags**: ai-strategy, machine-learning, physics, manufacturing, pinn **Reading Time**: 7 min **URL**: https://www.netrii.com/blog/pinns-when-physics-rescues-machine-learning Eight noisy measurements. A neural network that has never seen a downward arc. And yet — when Newton's second law is embedded into the loss function — the model predicts the apex, the asymmetric descent, and the landing point within centimeters. A 49× improvement that points to where ML is heading in physics-constrained domains. A neural network was given eight noisy position measurements from the first quarter of a projectile's flight — only the ascending phase, never any data showing the apex or the descent. Asked to predict the rest of the trajectory, the conventional model continued upward in a smooth, monotonically increasing curve. It had no idea the projectile was supposed to come down. The same architecture, trained on the same eight points but with Newton's second law and the aerodynamic drag force embedded directly into its loss function, produced the full trajectory — apex, asymmetric descent, ground impact — within centimeters of the truth. The two models differed only by what they knew about the world. > **Key point:** A pure data-driven neural network and a physics-informed neural network with identical architecture, trained on the same sparse, noisy data, produced extrapolation errors that differed by **49× horizontally and 53× vertically**. The only difference was the loss function. That headline result comes from a brief I just published in the netrii Wisdom Library — a controlled study extending physics-informed neural networks (PINNs) from the well-behaved 1D damped oscillator to a nonlinear, coupled, two-dimensional system: a sphere moving through air under gravity and quadratic aerodynamic drag, with no closed-form analytical solution. The full technical detail, equations, and figures are there. This post is for the operator who needs to know **when this lever applies and what it changes about how you think about ML in engineering domains.** ## The brittle-curve-fitting problem The conventional neural network in this study was not undertrained, badly architected, or unlucky. Four hidden layers, 64 neurons each, tanh activations, 2000 epochs of Adam with cosine-annealed learning rate. It fit the eight training points beautifully. The failure was not in the training region. The failure was the moment it stepped outside. This is the failure mode every engineer who has tried to deploy a data-driven model into a physical system has eventually run into. **Inside the training distribution, the model looks brilliant. Outside it, the model has no opinion that is grounded in anything real**, because nothing in its loss function ever told it that the world has structure. Drop a measurement gap, change an operating regime, ask the model to predict beyond its sampled domain — and the smooth tanh-shaped curves it learned do whatever extrapolation looks locally plausible. Plausible to a curve, not plausible to nature. For pure-data domains — language, vision, recommender systems — there is no governing equation to embed, and we live with the brittleness by collecting more data. For physical systems, that response is not just expensive. It is often impossible. The data is sparse because measurements are expensive, sensors are limited, regimes are rare, or the regime you care about is the one you have not seen yet. The faster horse here is "collect more data." The automobile is "tell the network what physics already knows." ## What the physics residual actually buys you The PINN is not a different network. It is the same network with a different loss. Three terms instead of one: - **Data loss.** The mean-squared error against the eight noisy measurements, exactly as before. - **Physics residual.** At a few hundred *collocation points* sampled across the entire flight time — including all the times for which there is no measurement — the network's predictions are differentiated using PyTorch's autograd, and the resulting acceleration is checked against `m·d²x/dt² = -b·|v|·dx/dt` and `m·d²y/dt² = -m·g - b·|v|·dy/dt`. Any violation is squared and added to the loss. - **Initial-condition loss.** A penalty if the network does not start the trajectory at the origin. That is the whole trick. The derivatives are computed *exactly* by automatic differentiation, not approximated by finite differences. If the residual is zero everywhere, the network's output satisfies Newton's second law exactly. The optimizer is now searching a much smaller manifold — the space of physically admissible trajectories — instead of the full space of curves. > **Key point:** The physics residual is an *inductive bias* — it constrains the optimizer to solutions consistent with the governing equations. This is mathematically analogous to Tikhonov regularization, but grounded in physical law rather than an arbitrary smoothness prior. When you actually know the law, that distinction is decisive. A subtle consequence emerges in the noise robustness experiment. We re-ran the study with five times heavier measurement noise (σ = 1.5 m). The conventional network overfit to the scatter and produced a foreshortened, distorted flight profile. The PINN refused to. The physics residual *penalized* trajectories that fit the noise but violated Newton's law — so the optimizer was steered toward the physically consistent path even when the noisy data suggested otherwise. **The known physics functioned as a regularizer that the noisy data could not overpower.** That is something no amount of dropout, weight decay, or smoothness prior can replicate, because none of them know what's true. ## Where this lever actually applies A 49×–53× extrapolation improvement is the kind of number that invites overgeneralization. Let me be precise about where this matters and where it does not. **The lever applies cleanly when all of the following are true:** - **The governing equations are known.** Conservation laws, transport equations, constitutive relations, ODEs/PDEs that describe how the system has to behave. Newton's second law in this study; the heat equation, Navier–Stokes, drift-diffusion, magnetization dynamics, Maxwell's equations in others. - **Data is sparse, noisy, or expensive.** If you can collect a million labeled examples cheaply, the data-driven baseline will close the gap on its own. PINNs earn their keep when each measurement costs a wafer, an hour of beam time, a destructive test, or a regulatory cycle. - **You need to predict outside the sampled regime.** Apex prediction from ascending data only is the toy version of this. The real version is predicting yield in process windows you have not run, fatigue beyond the test envelope, or device behavior in operating regimes you have not characterized. - **No closed-form analytical solution exists or it is computationally prohibitive.** If a fast analytical or numerical solver already handles the problem, use it. PINNs win where the equations are known but solving them is harder than learning a network that satisfies them. These are precisely the conditions in **manufacturing process control, semiconductor yield modeling, magnetic recording physics, fluid dynamics in design, and physics-aware optimization in quantum systems** — the domains where I have spent most of my career, and the domains where most of the sparse-data, expensive-measurement, governing-equation-known problems actually live. **The lever does not apply** to language modeling, vision, recommendation, or any domain where the "law" is statistical regularity in human-generated data rather than a differential equation. There is no Newton's second law of customer churn. Use PINNs where physics rules; use data-driven ML where it does not. ## A clean operating contrast | Dimension | Data-only neural network | Physics-informed neural network | | --- | --- | --- | | Behavior inside training data | Excellent fit | Excellent fit | | Behavior outside training data | Brittle; extrapolates as a curve | Constrained to physically admissible trajectories | | Sensitivity to measurement noise | Fits the noise | Penalized by physics residual; resists overfitting | | Data volume required | Large for the regime of interest | Small if equations are known | | Applicable when no closed form exists | Yes, but unreliable | Yes, and the headline use case | | Applicable when no governing equation exists | Yes | No — there is nothing to embed | The asymmetry matters. The PINN is not strictly better — it is better *exactly when you can name the law*. That is the strategic decision: not "should we use AI here," but "do we know enough physics to get an order of magnitude more out of the same data?" ## The forward question The result in this brief is not new in spirit — Raissi and colleagues laid out the PINN framework in 2019, and there is now a growing literature on scientific machine learning. What is useful about this study is that it is a clean, controlled, reproducible demonstration on a problem with no analytical solution, and it shows the noise-robustness behavior in an experiment small enough to fit in five pages and intuit immediately. **The operating implication for any organization doing engineering ML is this:** before you spend the next quarter collecting more data, ask which of your problems have governing equations you have not put into the model. If the answer is "most of them," the leverage is not in more data. It is in writing the loss function correctly. The harder question — and the one I am most interested in working through with operators — is which of your specific systems are PINN-shaped, and which look like they should be but quietly are not (because the governing equations are too uncertain, the system is too coupled with unmodeled effects, or the constraints conflict with the data in ways that destabilize training rather than regularize it). That is a conversation worth having before the architecture choice, not after. --- *This post is a companion essay to the technical brief* **Physics-Informed Neural Networks for Projectile Trajectory Prediction Under Quadratic Aerodynamic Drag** *(S. Batra, University of Minnesota ECE, 2026), now available in the netrii [Wisdom Library](/wisdom/pinns-projectile-trajectory). The brief contains the full equations, training-loss formulation, and figures.* --- ### Loosely Coupled, Tightly Integrated: The Microservices Principle as the Org Shape AI Demands **Date**: April 24, 2026 **Author**: Arun Batchu, David Quimby **Tags**: ai-strategy, organizational-design, contradictions, q4, change-management **Reading Time**: 5 min **URL**: https://www.netrii.com/blog/loosely-coupled-tightly-integrated The most adaptive software systems of the last twenty years are loosely coupled and tightly integrated. The most adaptive organizations of the next twenty will be the same. The microservices principle separates operational coupling from interface integration — and that separation is the org shape AI leverage actually demands. The most adaptive software systems of the last twenty years are loosely coupled and tightly integrated. The most adaptive organizations of the next twenty will be the same. That sentence sounds like a slogan; it is actually a load-bearing operating principle, and most reorgs fail because leaders treat its two halves as the same thing. > **The trap:** treating *operational coupling* and *interface integration* as one axis. They are two. That conflation is the reason most "agile transformations" land in chaos and most "platform consolidations" land in molasses. ## The principle, briefly In well-run microservice architectures, services own their data, deploy independently, and integrate with each other through clean, versioned contracts. Two distinct properties hold at the same time: - Loose operational coupling. A service can change, ship, recover, and scale on its own schedule, without coordinating with every other service. - Tight interface integration. The contract between services is precise, enforced, and treated as a first-class artifact. Calls do not cross boundaries by accident. Software teams who internalized this twenty years ago discovered something counterintuitive: **the contract is what makes the autonomy safe**. Without it, "autonomous" services produce a federation of incompatible versions of the truth. With it, they produce a system that ships continuously *and* composes coherently. The interesting move is to apply the same lens to a commercial organization. ## The org-design contradiction Most org charts encode an unspoken belief: that you have to choose between control and speed. Tighten coupling for cohesion and accept the slowness. Loosen it for speed and accept the divergence. The choice gets re-litigated every five years under different language — centralize, decentralize, federate, consolidate — and every five years, neither answer survives contact with the next environmental shift. The TRIZ frame for this is straightforward. *The contradiction is real only because the wrong axis is chosen.* When you treat coupling and integration as the same dimension, the choice is binary and bad. When you separate them — coupling on one axis, integration on the other — the binary collapses, and a fourth posture appears. Click each quadrant for the operating shape and where real organizations actually live. Most enterprises drift toward **Q1, the Committee** — central control without clean contracts. The most common ambitious move is **Q2, the Federation**, dressed up as "empowered teams" — and it is the seductive trap of the post, because it feels like progress and is actually fragmentation. **Q3, the Cathedral**, is the honest monolith: coherent, governed, slow. **Q4, the Modular Organization**, is the goal: autonomous teams bound by clean contracts. ## Why this matters more for AI than for anything before it Loose coupling and tight integration have always been good systems hygiene. AI raises the stakes by an order of magnitude, because of how AI leverage actually behaves inside a team. - Leverage compounds inside the team that owns the stack. An AI capability that a function owns end-to-end — its own data, its own model deployment, its own feedback loop — gets better every week. The team learns where it fails, retrains, instruments, and tightens. - Leverage leaks at every handoff. The same AI capability piped through a cross-functional handoff loses context, accumulates committee compromises, and decays. The numbers a Federation team reports do not match the numbers the next team needs to consume. - Contracts protect the leverage. A clean contract between teams is a place where leverage can survive a boundary crossing. Without one, the leverage stays a local optimization that never makes it to the customer. This is the operational reason **Q4 is where AI economics actually live**. It is not because Q4 organizations are "more innovative." It is because their boundaries are designed to let leverage compound inside a team and to let *the right summary* of that leverage cross to the next team. The Cathedral cannot move fast enough to capture the leverage. The Federation cannot integrate cleanly enough to keep it. The Committee never had it in the first place. > **The deeper claim:** AI does not reorganize companies. AI exposes the cost of bad organization. The companies that look like they are pulling ahead are usually the ones whose contracts were already clean enough to let leverage compound. ## The hard part is not dissolving the central function The reflex when teams hear "loose coupling" is to dissolve the central function. Break up the monolithic platform team. Push autonomy down. Watch what happens. What happens is the Federation. Without contracts, autonomy produces divergence. The dashboards splinter. The customer experience develops seams. AI projects duplicate, with subtle differences in how each team defines the same business object. Eventually a senior leader notices the cost, and the org swings back toward the Cathedral. The hard part is the part most reorgs skip: **designing the contracts**. What does each function produce for the rest of the business? At what cadence, at what quality bar, with what versioning policy? Who is the owner? What is the deprecation rule? When the contract changes, who finds out, and how? These are not architecture questions. They are operating-model questions, dressed in architecture language. They look boring. They are the work. ## The lever Most reorgs fail because they move boxes without changing contracts. The new chart looks different. The work crosses the same handoffs as before, with the same informal tribal knowledge as the integration mechanism. Six months later, the new shape settles back into the old behavior, because nothing about the boundaries actually changed. The lever is the contract. **A reorg that does not produce a written, versioned, owned contract for each new boundary is not a reorg; it is a redraw.** A reorg that does is a different system. ## What we are watching next Two open questions, both worth a future post. The first is which contracts AI is going to make harder to write — and which it is going to make trivially easy. Real-time semantic translation between team-specific schemas, automated contract testing, and AI-mediated handoffs may dissolve some of the ceremony that made contracts feel expensive. They may also create a temptation to skip the contract entirely on the theory that the AI will sort it out. We expect both effects, in different teams, in the same year. The second is how to build the contract muscle in an organization that has only ever lived in the Committee or the Cathedral. The shift to Q4 is not a kickoff offsite. It is dozens of small contract-writing exercises, each of which feels like overhead until the seventh time the contract saves a project. The work is not glamorous. It is the actual lever. The strategic implication, for any leader looking at the matrix and seeing their organization in Q1 or Q2: **the move is not to become more autonomous, and not to become more controlled. The move is to write contracts.** That is what makes Q4 possible. It is also what most reorgs forget. --- ### The Faster-Horse Trap in AI Adoption **Date**: April 18, 2026 **Author**: Megan C. Starkey, David Quimby, Rick Tanler, Arun Batchu **Tags**: ai-strategy, innovation, leadership, change-management, product-strategy **Reading Time**: 4 min **URL**: https://www.netrii.com/blog/the-faster-horse-trap-in-ai-adoption Most organizations deploying AI today are breeding faster horses — bolting LLMs onto existing workflows to claim a win without changing anything. The automobile shift has not happened yet, and the Ford quote everyone misquotes shows why. > **The trap:** Most organizations deploying AI today are breeding faster horses. They are not building automobiles. The quote "If I had asked people what they wanted, they would have said faster horses" is almost universally attributed to Henry Ford. No primary source has ever been found for it. It does not appear in Ford's own books or interviews, and the earliest known print attribution traces to a 2006 Harvard Business School Press title — fifty-nine years after Ford's death. The attribution is apocryphal. The *observation*, however, is real, and it describes the single most common failure mode in AI adoption right now. ## The contradiction The failure mode is a contradiction that most enterprise AI programs refuse to name: *we want transformational results without changing how anyone works.* That belief looks reasonable one pilot at a time and absurd when you lay the whole portfolio out on two axes — the shape of the organization and the ceiling on the payoff. Four postures fall out. Three of them are traps. Click each quadrant for the shape of the bet and where real deployments actually land. The four AI examples most teams point to — email drafting, meeting summaries, code autocomplete, chatbots over search — are not randomly distributed. They cluster in **Q1, the Faster Horse quadrant**: incremental gains inside the existing org. It is the only quadrant that lets leaders claim a win without paying political cost. That cluster is the trap. **Q3, the Exoskeleton**, is how the trap is disguised — the same pilots repackaged in transformational language to make Q1 look like Q4. ## Why teams default to Q1 The faster-horse reflex is not a failure of imagination. It is a failure of incentive structure. A Q1 bet: - Fits cleanly into the current org chart - Has a measurable before-and-after ("we saved twenty percent on email time") - Does not threaten the ownership of any workflow - Can be piloted inside one team without cross-functional buy-in A Q4 bet does none of those. It redraws the org chart. It replaces a measurable task with a different shape of work. It threatens the people who own the current workflow. And it cannot be piloted inside one team — it requires reorganizing how work flows between teams. > **Operating reality:** The faster horse is not a strategic choice. It is the highest-feasibility option that lets an organization claim an AI win without changing anything. ## The diagnostic question The question worth asking every leader piloting AI is narrow and unflattering: *if this pilot succeeds beyond your best-case projection, does the org chart need to change?* If the answer is *no*, you are in Q1 or Q3 — a faster horse or an exoskeleton. Q1 is the honest version; Q3 is the pitch-deck version. Either way, the org shape caps what AI can reach, and you will be out-competed by anyone willing to rewire the workflow. If the answer is *yes* — fewer roles, merged functions, entire pipelines disappearing — you are either in Q2 (costly reorg, thin payoff) or Q4 (costly reorg, non-linear payoff). The job of strategy is to make sure the bet lands in Q4 and not Q2. There is no fifth quadrant where the technology is transformational and the org is unchanged. Q3 is the fantasy that one exists. ## What to do next - **Audit your AI pilots.** Place each one in the matrix. Most will land in Q1 or Q3 — either a faster horse or an exoskeleton claim on top of one. That is fine as a starting point. It is not fine as an ending point. - **Name the Q4 version of each Q1 pilot.** Even if you cannot ship it yet, force the team to articulate what the non-incremental version would look like. The gap between the two is the real strategic question. - **Budget for at least one Q4 bet.** Not every program has to be transformative, but a portfolio of only faster horses is a slow-motion loss. The useful part of the Ford myth is not the quote. It is the discipline of refusing to treat a new primitive as an add-on to the old workflow. AI is not autocomplete for the existing business. It is a chance to notice that the business was never shaped like that in the first place. --- ### Your AI Assistant Should Know What Page You're On **Date**: April 15, 2026 **Author**: Arun Batchu **Tags**: ai-strategy, conversation-design, product-design, ux **Reading Time**: 5 min **URL**: https://www.netrii.com/blog/your-ai-assistant-should-know-what-page-youre-on Most embedded AI assistants are context-blind — same generic answers whether you're reading about GPU architecture or dementia care. The fix isn't better prompts. It's situational awareness. Most organizations that embed an AI assistant on their website make the same mistake: **the assistant has no idea what the user is looking at.** Someone is reading a deep technical brief about GPU memory hierarchies. They open the assistant. The first suggested question is "What does your company do?" That is not a conversation. That is a search box with a personality. > **The real problem is not intelligence. It is attention.** A context-blind assistant forces the user to re-explain where they are and what they care about. A context-aware assistant meets them in the middle of the thought they are already having. ## The cost of context blindness When an assistant ignores page context, three things happen: - Questions are generic. "Tell me about your services" when the user is already reading about a specific service. The assistant becomes a worse version of the navigation menu. - Answers miss the mark. The user asks about a concept mentioned on the page. The assistant responds with a generic overview instead of connecting to the specific research, expert, or case study they are viewing. - Engagement dies at first contact. The user tries one question, gets a boilerplate response, and never opens the assistant again. The investment in AI becomes a decorative feature. This is not a prompt engineering problem. The model is capable. The failure is architectural: **nobody told the assistant where the user is standing.** ## What changes when the assistant knows the page The shift is simple in concept and dramatic in effect. When the assistant knows the user is viewing a specific expert's profile, it can: - Suggest questions about that expert's specific work, not generic "who are your team members?" - Reference the expert's published research, projects, and philosophy - Connect the user to related content they would not have found through browsing When the user is reading a research brief, the assistant can: - Help them understand the key arguments and apply the insights - Surface related briefs, blog posts, or experts who work in the same domain - Offer to visualize the concept relationships in the paper When the user is exploring a knowledge graph, the assistant becomes a guide to the intellectual territory they are navigating. > **Key insight:** The value of page context is not just better answers. It is better *questions*. The suggested questions the assistant surfaces should be things the user would not have thought to ask on their own — but that are obviously relevant once they see them. ## The pattern, not the implementation The principle generalizes across any organization embedding AI: - Map your content topology. Know what types of pages exist and what makes each type distinct. A product page has different conversational potential than a blog post or a team profile. - Pass context, not content. The assistant does not need the full page text. It needs enough metadata to orient itself — what kind of page, which entity, what domain. - Adapt both the prompt and the suggestions. Context should shape the system prompt (what the model knows about the current situation) and the suggested questions (what the user sees before they type anything). - Treat navigation as conversation signal. When a user moves from one page to another, the assistant should acknowledge the shift. "Ask about this page" is a more useful prompt than stale follow-ups from a previous context. ## Why this matters for organizations The embedded AI assistant is becoming table stakes. Within two years, every serious professional services site, research platform, and knowledge hub will have one. The competitive question is not whether you have an assistant. It is whether your assistant is paying attention. A context-aware assistant turns a website from a collection of pages into a guided experience. It transforms passive reading into active inquiry. And it surfaces the kind of unexpected connections — between an expert's background and a research paper, between a blog post and a methodology — that justify the entire investment in structured knowledge. The better question is not "how smart is your AI?" It is: **does your AI know where the conversation is happening?** --- ### Research Trapped in Documents Doesn't Compound **Date**: April 15, 2026 **Author**: Arun Batchu & Sharat Batra, PhD **Tags**: ai-strategy, knowledge-management, content-operations, infrastructure **Reading Time**: 6 min **URL**: https://www.netrii.com/blog/research-trapped-in-documents-doesnt-compound A PDF sits in a folder. A structured web page creates nodes in a knowledge graph, feeds an AI assistant, and gets richer every time new content connects to it. The container you choose determines whether wisdom accumulates or stagnates. A senior technologist spends three weeks writing a definitive analysis of AI infrastructure — the kind of work that synthesizes decades of hardware expertise, market intelligence, and architectural judgment into a document that could save an organization millions in misallocated capital. The output is a Word document. It gets emailed to a distribution list, downloaded by a few people, and filed. **That is where the wisdom dies.** > **The verdict:** PDFs and Word documents are containers — useful for transport, terrible for accumulation. Research locked inside documents does not feed knowledge graphs, does not get discovered by AI assistants, does not connect to other concepts, and does not compound. The format you publish in determines whether your intellectual capital appreciates or depreciates. ## The document trap Most organizations treat research output as a publishing problem: write it, format it, distribute it, done. The document — whether PDF, DOCX, or PPTX — is the final artifact. It sits in a SharePoint folder, a Google Drive, or an email attachment chain. If someone remembers it exists and can find it, they might read it. If they cannot, it is as if the work never happened. This is not a storage problem. It is a *compounding* problem. A document is a dead end in a knowledge network. It has no connections to related research. It does not surface when someone asks an AI assistant a question in the same domain. It does not appear as a node in a concept graph where its ideas could link to adjacent expertise. It does not update the organization's capability metrics or contribute to the breadth that makes a network valuable. The document is complete and inert. That is the trap. ## What happens when you unpack Consider what changes when the same research is published as structured, living web content instead of a filed document: - Concepts become nodes. Every key theme in the research — GPU architecture, storage economics, supply chain constraints — becomes a tagged concept that links to every other piece of content touching the same idea. The research joins a knowledge graph. - The AI assistant learns it. An AI-powered assistant can now reference the research when a user asks a relevant question. The expert's judgment becomes available at the moment of need, not buried in a file tree. - Cross-connections emerge automatically. When a second expert publishes related work — say, on the operational side of infrastructure procurement — the knowledge graph creates edges between their concepts. Neither author planned the connection. The system surfaced it. - Capability metrics update. The organization's documented breadth and depth grow with each published piece. The network value is not additive — it is combinatorial. Five experts publishing across overlapping domains create far more insight paths than five experts publishing in isolation. > **Key insight:** The difference is not digitization. The difference is *structure*. A PDF on a website is still a dead end. Structured content with tagged concepts, linked authors, and searchable full text is a live node in an expanding network. ## Containers versus infrastructure The distinction is worth naming precisely. A document — PDF, DOCX, PPTX — is a **container**. It holds wisdom in a sealed format optimized for one-time reading. A structured web page with concept tags, author links, and full-text indexing is **infrastructure**. It holds the same wisdom in a format optimized for discovery, connection, and accumulation. Both can carry the same words. The difference is what happens after publication. - A container gets filed. It sits in a folder until someone remembers it exists. Its value decays with time and organizational memory. - Infrastructure gets woven. It connects to related content at the moment of publication. Its value increases as more content joins the network. Organizations that treat expert research as containers are systematically undervaluing their most expensive intellectual asset. The analysis that cost three weeks of senior expertise and decades of domain knowledge gets the same publication treatment as a meeting agenda. ## The compounding math This is where the economics become interesting. In a knowledge network where experts, research briefs, engineering dispatches, and tagged concepts all interconnect: - Adding one expert does not add one unit of value. It multiplies the connections between that expert's domains and every existing piece of content. - Publishing one research brief does not add one document. It adds concept nodes and co-occurrence edges that make every related concept more discoverable. - Each new piece of content makes every previous piece more valuable — because there are now more paths through the network that pass through it. This is Metcalfe's Law applied to organizational knowledge. The value of the network scales with the square of its nodes, not linearly with the count of its documents. But only if those nodes are connected. Documents in folders are not connected. Structured content in a knowledge graph is. ## The operating question Most organizations have research trapped in documents right now. Internal analyses, technical briefs, white papers, client deliverables, strategic memos — all sealed in containers that do not talk to each other. The operating question is not whether to keep producing documents. Some contexts demand them. The question is: **what is your strategy for unpacking the wisdom inside those documents into a form that compounds?** Every week that research sits in a PDF is a week it is not feeding your knowledge graph, not training your AI assistant, not connecting to adjacent expertise, and not contributing to the combinatorial value of your network. The container served its purpose. The wisdom inside it deserves better. --- ### From Textbook to Narrated Video in One Session **Date**: April 15, 2026 **Author**: Arun Batchu & Claude (AI) **Tags**: ai-agents, intelligent-textbooks, video, technical-communication, education **Reading Time**: 4 min **URL**: https://www.netrii.com/blog/from-textbook-to-narrated-video-in-one-session We generated a complete intelligent textbook, a 30-slide lecture deck, and a narrated video lecture — all in a single Claude Code session. The real lesson is not the speed. It is the pipeline. A complete intelligent textbook — 15 chapters, 63,000 words, 275 concepts, 150 quiz questions, interactive simulations — followed by a 30-slide lecture presentation and a narrated video lecture. **All generated in a single working session.** The textbook is *Mastering Technical Communication*, now live in the netrii Wisdom Library. The real story is not what we built. It is *how the pipeline works* — and what it means for anyone who needs to turn expertise into scalable educational content. ## The Pipeline That Did Not Exist Last Year A year ago, I gave a guest lecture on technical communication to ECE undergraduates. The students loved it. But when the lecture ended, there was no durable artifact. No textbook. No reference material. Just a slide deck and fading memory. This year, I started with the same lecture notes and student feedback. But instead of building another ephemeral slide deck, I ran a structured AI pipeline that produced: - **A course description** with Bloom's Taxonomy-aligned learning outcomes (scored 100/100 by the analyzer) - **A learning graph** — 275 concepts with 496 dependency edges, validated as a directed acyclic graph - **15 chapters** of detailed educational content, each 4,000-5,000 words, with Mermaid diagrams and mascot-guided pedagogy - **150 quiz questions** distributed across Bloom's cognitive levels - **A 275-term glossary**, 66-question FAQ, and 150 curated references - **5 interactive MicroSims** — a Pyramid Builder, Dilution Effect demo, Audience Analyzer, Presentation Timer, and Learning Graph Viewer > **Key point:** The textbook is not a draft or a prototype. It is a published, navigable, searchable MkDocs Material site with full chapter navigation, quizzes, and interactive simulations — deployed to production in the same session it was generated. ## From Textbook to Lecture Deck Here is where the contradiction surfaced. I tried using the textbook itself as the presentation medium for a class. It did not work. A textbook is a reference artifact — dense, comprehensive, designed for self-paced reading. A lecture is a performance — visual, story-driven, designed for a room full of people with four working memory slots and shrinking attention. The solution was to treat the textbook as the *knowledge base* and generate a separate presentation designed for live delivery. The deck follows a 4-act storytelling structure — not because storytelling is decorative, but because it is how the textbook's own Chapter 9 says information should be delivered. **The medium is the message.** Every slide exemplifies the principle it teaches. The result: 30 slides with structured speaker notes — timing cues, exact narration scripts, and what we call "meta-moments" where the speaker reveals the framework after demonstrating it. ## From Lecture Deck to Narrated Video The final step — and the one that surprised me most — was converting the slide deck into a narrated video. AI voice synthesis reads the speaker notes while each slide is displayed for the appropriate duration. The first attempt was hilariously bad. The voice narrated everything — including stage directions like "PAUSE 3 seconds" and "Notice what I just did? That was Klein's Dilemma stage." The narration engine does not know the difference between text meant for a speaker's eyes and text meant for an audience's ears. > **Key point:** The interesting engineering problem is not generating the audio. It is *preparing the text* — stripping stage directions, expanding abbreviations for natural speech, and calibrating inter-slide pacing so transitions feel human rather than mechanical. After two iterations, the video plays cleanly. Numbers read naturally. Transitions breathe. The narration sounds like a prepared lecture, not a robot reading a teleprompter. ## What This Means The pipeline from expertise to educational content just collapsed from months to hours: - **Course description → textbook → presentation → video** — each step builds on the previous one - **The textbook is the source of truth** — the presentation and video are derived artifacts, not independent creations - **Iteration is cheap** — fix a concept in the textbook, regenerate the downstream artifacts - **The skills are reusable** — the same pipeline that built the Technical Communication textbook works for any subject This is not about replacing educators. It is about giving them leverage. An expert with deep knowledge and a clear vision for their course can now produce a complete educational package — textbook, slides, and video — and publish it to learners who need it. The textbook is free in the [netrii Wisdom Library](https://www.netrii.com/wisdom). The lecture slides and narrated video are available alongside it. The pipeline keeps getting better with each use. The better question is not "can AI generate a textbook?" It is "what happens when generating educational content becomes as cheap as writing an email?" We are about to find out. --- ### Netrii Releases Free Online Dementia Care Guidebook **Date**: April 13, 2026 **Author**: Rick Tanler **Tags**: dementia, healthcare, community, built-by-us **Reading Time**: 3 min **URL**: https://www.netrii.com/blog/dementia-guidebook-press-release Understanding Dementia — 15 evidence-based chapters and an interactive knowledge portal with 200+ concepts — is now available for free at netrii.com. Dementia affects an estimated 55 million people worldwide. Tens of millions more serve as unpaid family caregivers. Despite the scale of the challenge, accessible, trustworthy, and well-organized information remains difficult to find in one place. That is the problem we set out to solve. Today we are releasing **Understanding Dementia** — a comprehensive, free online guidebook designed to support families and caregivers navigating the complexities of dementia care. It is available immediately at netrii.com/built-by-us/dementia-liquid. ## What the guidebook covers Understanding Dementia spans 15 evidence-based chapters covering the full spectrum of dementia care: - Introduction to dementia and its types - Diagnosis and clinical assessment - Daily living and caregiving strategies - Managing behavioral changes - Therapeutic interventions - Legal and financial planning - Home safety and modifications - End-of-life stages and support Every chapter is written at a 9th-to-10th-grade reading level with evidence-based guidance in plain language. The goal is practical utility, not clinical abstraction. ## The Knowledge Portal Alongside the guidebook, we built an interactive **Dementia Knowledge Portal** — a visual map of over 200 dementia-related concepts across 12 taxonomy categories. It gives users an intuitive way to explore and connect information that is normally scattered across dozens of sources. The portal is built on a structured learning graph with dependency chains between concepts. It is the same methodology we use across all our intelligent textbooks — applied here to a domain where the stakes are personal and the need for clarity is highest. ## Why we built this > "We wanted to build something genuinely useful for the people navigating one of the hardest situations a family can face. This guidebook puts evidence-based guidance in plain language — for free, and available to everyone." > > — **Richard Tanler**, Netrii Understanding Dementia is part of Netrii's Built by Us initiative — a series of public-good digital tools built to demonstrate the power of thoughtful AI technology applied to real human challenges. The underlying textbook was built by Rick Tanler using Dan McCreary's intelligent textbook methodology, with 200 concepts, interactive MicroSims, quizzes, and a glossary. The same engineering patterns — learning graphs, concept taxonomies, interactive knowledge portals — that power our commercial work are applied here to a cause that matters. The technology is the same. The audience is different. The value is the same. Access the guidebook → --- ### The Bike Shop Simulator Makes Theory of Constraints Visible **Date**: March 25, 2026 **Author**: Arun Batchu & Cascade (AI) **Tags**: simulators, constraints, systems-thinking, operations **Reading Time**: 6 min **URL**: https://www.netrii.com/blog/bike-shop-toc-simulator Theory of Constraints is easy to explain and hard to internalize. The bike shop simulator compresses the idea into a few minutes of hands-on play: find the bottleneck, watch work pile up, move the constraint, and see why local efficiency is not the same thing as system throughput. Most teams do not need another definition of Theory of Constraints. They need a way to see it happen. The bike shop simulator is built for that job. It takes a production line that could turn abstract in a slide deck and turns it into something you can manipulate directly. That is the point. The moment you can move the line yourself, the lesson stops being theoretical. You see the queue form. You see where work piles up. You see why improving the wrong station can make the system look busier without making it better. ## Why a simulator works better than another explanation TOC is one of those frameworks that sounds obvious until you actually have to operate by it. Everyone agrees the constraint matters. Fewer teams are good at seeing where the constraint is, how it shifts, and what to do next. A simulator gives the system back to the reader in a form they can inspect. - It makes WIP visible. You do not have to infer where the backlog is building; you can watch it accumulate. - It shows the cost of local optimization. Raising capacity in the wrong place feels productive and still fails to improve throughput. - It turns the Five Focusing Steps into an experience. Identify, exploit, subordinate, elevate, and repeat becomes a loop, not a slogan. That is why the bike shop simulator matters. It is not trying to be a realistic factory model. It is trying to make one durable operating principle impossible to miss: throughput belongs to the system, not the loudest station. ## What changes when you play with the line The interesting part is not that the constraint exists. The interesting part is how fast the rest of the line responds once you touch it. Move capacity upstream and the queue can get worse. Improve a non-constraint and the graph may look healthier without changing the outcome. Fix the real bottleneck and the whole system breathes differently. That is the hidden value of an interactive model. It gives the reader a cheap place to make mistakes. And in systems work, cheap mistakes are valuable. They teach faster than polished explanations because the system answers back. Try the Bike Shop Simulator → It takes only a couple of minutes to see the line, move the constraint, and understand why TOC is really about flow, not activity. > The real lesson: the fastest way to teach constraint thinking is to let people feel the system push back. ## What the simulator is really for 1. Teach one idea clearly. The simulator should make the bottleneck obvious within seconds. 2. Keep the interaction calm. If the experience is noisy, the lesson gets buried under the interface. 3. Connect insight to action. The goal is not novelty. The goal is to leave with a better operating instinct. That is the real reason to build the bike shop simulator: it gives people a place to see Theory of Constraints before they have to manage a real one. Once you have watched the line respond, the framework is harder to forget and easier to use. --- ### The SDLC Simulator Shows Why Delivery Slows Before Code Does **Date**: March 25, 2026 **Author**: Arun Batchu & Cascade (AI) **Tags**: simulators, constraints, software-delivery, engineering-ops **Reading Time**: 6 min **URL**: https://www.netrii.com/blog/sdlc-toc-simulator Most software teams think their bottleneck lives in coding speed. The SDLC simulator shows a different reality: delivery usually slows because of handoffs, queues, reviews, and context switching. Once you can see the work move, the operating problem becomes much easier to name. Software teams love to measure activity. Story points go up. Pull requests move. Standups happen. Yet lead time still stretches, release dates still slip, and everyone still feels busy. That gap between motion and flow is where the real constraint lives. The SDLC simulator is built to make that gap visible. It compresses the software delivery lifecycle into a simple system you can manipulate directly. Instead of discussing bottlenecks as an abstract management concern, you can watch them form in front of you. ## Why software teams need a constraint simulator Most delivery problems are not caused by a single underperforming engineer. They come from the shape of the system: too much work in flight, too many handoffs, too much waiting, and too much optimism about how fast one step can move when the next step is already overloaded. - Queues hide in plain sight. Work sits in review, QA, or release prep longer than teams expect. - Local speed is not system speed. A faster coding stage does not help if downstream work is already full. - Context switching is a tax. The more simultaneous work in the system, the more time gets burned just reloading context. That is why the simulator matters. It gives a software team a place to see the operating system of delivery, not just the code. Once that system is visible, the conversation changes from 'Who is slow?' to 'Where is flow breaking?' ## What the SDLC simulator reveals The useful lesson is not that software development is complicated. The useful lesson is that delivery slows long before the code is done. Requirements can queue. Reviews can pile up. QA can become the constraint. Release coordination can become the hidden bottleneck. The system is telling you where the pressure lives if you know how to look. When teams see this in a simulator, they usually notice two things. First, adding more work can make the system worse. Second, improving the wrong stage can create the illusion of progress without changing the end-to-end result. Those are exactly the kinds of mistakes TOC is meant to prevent. Try the SDLC Simulator → Watch the flow, surface the bottleneck, and see how quickly throughput changes once the constraint is identified correctly. > The real lesson: if delivery feels slow, the problem is often not the people doing the work. It is the system that shapes the work. ## What leaders should take from it 1. Measure flow, not just effort. Output metrics are not enough if the work is stuck in queues. 2. Reduce work in progress. Less simultaneous work usually means faster completion and less hidden delay. 3. Manage the constraint directly. Elevate the bottleneck that actually governs delivery, not the one that is easiest to talk about. The SDLC simulator exists for the same reason the bike shop simulator exists: to turn an operating idea into something you can feel. Once the delivery system is visible, the next conversation is no longer about blame. It is about design. --- ### Why We’re Launching a Simulators Program **Date**: March 25, 2026 **Author**: Arun Batchu & Cascade (AI) **Tags**: simulators, systems-thinking, ai-strategy, constraints **Reading Time**: 6 min **URL**: https://www.netrii.com/blog/launching-the-simulators-program AI is making it easier to build subsystems and systems of systems. That shifts the bottleneck toward judgment: what to build, what to constrain, and how to understand the whole system before it gets too easy to assemble the wrong one quickly. Our new simulators program starts with a Theory of Constraints bike simulator for exactly that reason. AI is changing the shape of building. It is getting easier to assemble a subsystem, wire a workflow, spin up an interface, and connect one tool to the next. What used to take a small team and a long calendar now takes a few focused people and much less time. That is a real advantage. It is also a warning. The faster we can build systems of systems, the easier it becomes to build the wrong one quickly. That is the local bug. The larger systems issue is that the constraint moves. It is no longer just code generation or component assembly. It is judgment: what matters, where flow stalls, and how to make the whole system easier to see. ## Why a Simulators Program We are launching simulators because some ideas are easier to understand when you can manipulate them directly. A good simulator compresses a system into enough structure to make the underlying logic visible without pretending the real world is simple. It gives you a place to test a mental model before you depend on it. - It shows where the constraint sits. - It makes tradeoffs visible. - It turns a concept into a repeatable experience. This matters more as AI lowers the cost of building. If it becomes cheap to create features, dashboards, agents, and automated subsystems, then the value shifts toward understanding the system those pieces create together. A simulator is a way to make that system legible. ## The First Simulator: Bike Production and Theory of Constraints Our first simulator models a bike production line. It is deliberately narrow. That is the point. You can see a bottleneck, watch WIP accumulate, apply the Five Focusing Steps, and see the system respond. The experience is not trying to be a digital twin of a factory. It is trying to teach one durable idea: throughput is a property of the system, not the loudest station. That makes the bike simulator a useful first step for a broader program. It is small enough to understand quickly, but rich enough to reveal the dynamics that matter. Once you see the constraint move, the idea stops being theoretical. Try the simulator yourself → It takes about two minutes. Start the line, watch the bottleneck emerge, and use the built-in AI guide to connect what you see to the deeper logic of TOC. > **The real lesson:** when a system gets more capable, constraint thinking matters more, not less. ## AI Makes Building Faster. Thinking Is Still the Bottleneck There is a temptation to treat AI as a force multiplier that reduces the need for structure. It does reduce build friction. It also increases the number of things that can be assembled before anyone has asked whether the assembly is coherent. Faster construction does not remove the need for judgment. It raises the cost of being wrong about the system. That is why simulators are useful. They slow the mind down in the right way. They let you inspect the effect of a decision without needing to ship the full system first. They create a cheap place to reason before the expensive version exists. ## What We Want the Program To Become Over time, the simulators program should become a small library of focused experiences: operations, constraints, decision-making, and systems behavior. Each one should be simple enough to approach quickly and rich enough to reward a second pass. The goal is not novelty. The goal is clarity. 1. Model one important idea clearly. 2. Make the interaction smooth enough that people keep going. 3. Connect the experience back to a real operating principle. The broader pattern is straightforward: as AI accelerates subsystem creation, the premium moves toward systems thinking. The organizations that win will not just build faster. They will understand faster. That is what the simulators program is for. > See it for yourself: Open the TOC Bike Simulator → Watch the bottleneck form. Apply the Five Focusing Steps. Ask the AI assistant anything about what you are seeing. It is the fastest way to make TOC feel real. --- ## Contact Website: https://www.netrii.com Founder email: arun@netrii.com