Before building enterprise AI systems, I worked on the economy design for DeFight Club, a Web3 game. Items, rarity tiers, building progression, and resource flows had to fit together. That experience shaped how I think about interconnected systems.
The transferable lesson was to examine dependencies: a change to one part can alter the behavior of the rest. In AI systems, that includes knowledge, permissions, integrations, and review workflows.
The Unexpected Connection
At first glance, game economy design and enterprise AI infrastructure seem unrelated. One involves drop rates and crafting matrices. The other involves knowledge bases and API integrations.
But the core challenge is identical: design a complex, interconnected system where changes in one area ripple through everything else, and the entire system needs to work reliably at scale.
In game economy, if your crafting costs are wrong, players hit a wall at level 12 and quit. In enterprise AI, if your knowledge structure is wrong, the AI gives confident but incorrect answers and the team stops trusting it.
Both failures come from the same root cause — not understanding how systems connect.
What Game Economy Teaches About Structure
For a catalog of interconnected items, define shared relationships between rarity, progression, resource costs, and crafting time. A matrix makes assumptions explicit and helps identify how a parameter change propagates; its outputs still need validation.
This is exactly how a well-built knowledge base works. You don’t write 200 documents independently. You create a structure — categories, cross-references, access levels, naming conventions — and the structure ensures consistency as the system grows.
In DeFight Club, rarity and progression provided a shared structure for item definitions. The lesson is to keep relationships explicit so adding an item does not silently introduce a conflicting cost or power rule.
In enterprise AI, our knowledge bases use similar hierarchical structures. Categories, subcategories, access levels, document types. Adding new knowledge means placing it in the right node, not reinventing the organization.
Multi-System Thinking
A game economy is never one system. In DeFight Club, the building economy fed into the crafting system, which produced items for the battle system, which generated rewards that went back into buildings. Change the resource output of a single mine, and it affects crafting speed, item availability, battle outcomes, and token circulation.
Enterprise AI infrastructure has the same interconnections. The knowledge base feeds the AI assistant, which generates responses that flow through MCP integrations to Google Workspace, which produces data that loops back into the knowledge base.
Understanding these feedback loops — where they create virtuous cycles and where they create problems — is the core skill that transfers between domains.
Economy Simulation → System Validation
I used Machinations to explore DeFight Club's resource flows and reward curves. The engineering lesson is to record simulation assumptions and test changes before relying on their results; a model's output is evidence about those assumptions, not proof of production success.
The same mindset applies to AI systems. Before deploying a knowledge base, we model the information flow. Which questions will users ask? What data does the AI need to answer them? Where are the gaps? Where might the AI hallucinate because the underlying knowledge is missing or ambiguous?
Most AI projects skip this step. They dump documents into a folder, connect an AI, and wonder why the answers are unreliable. That’s like launching a game economy without testing whether the math works.
AI as a Productivity Multiplier
Working on DeFight Club meant connecting item definitions, building progression, quest chains, and drop tables. That experience made schemas, conventions, and validation rules central to my workflow.
I built a custom AI workflow around backend specifications, database schemas, validation rules, and naming conventions. Generated data still needed review against those constraints before use; the lesson was to design the context and the checks together.
The useful lesson is a repeatable review process: explicit inputs, generated artifacts, validation, and a decision about what is ready to use.
In our enterprise work, that approach means defining the knowledge architecture, templates, and conventions before using AI to generate or structure content. Review the resulting material against its sources and access rules.
The Systems Architect Advantage
The AI consulting market is full of prompt engineers and chatbot builders. What’s rare is someone who can design the entire system — the knowledge architecture, the integration layer, the access control model, the data flow, the governance rules — and make all the pieces work together.
That’s what game economy design teaches. Not how to write prompts, but how to think in systems.
What This Means in Practice
When a client comes to us with scattered knowledge across 5 platforms, we don’t start by connecting AI to everything. We start by designing the structure. What are the categories? How do they relate? Who needs access to what? What are the data flows?
This is the same process as designing a game economy. Start with the structure, model the flows, validate the balance, then build.
Before treating an architecture as ready to scale, test its data flows, access boundaries, failure behavior, and maintenance process. Shared structure helps manage change, but production reliability needs evidence from the actual deployment.
For a practical guide on the structuring methodology itself, see How to Structure Company Knowledge for AI. And for a deep dive into how MCP connects AI to business tools, check MCP Explained.
Want a systems architect to design your AI infrastructure? Explore our Full AI Transformation or see the European construction company case study for a real example.