In my last post, I introduced the idea of Logic Entombment. Business rules that are so tightly coupled with additional work overhead and infrastructure that no external system can reach them cleanly. Today, I want to get into why this is specifically bad for AI agents. Not just inconvenient. Actively hostile.
I wrote about monoliths back in 2015, and the core observation I made then was that a monolith isn't a bad choice early on. It's actually the right choice for many organizations getting started. The problem is what happens over time as the codebase grows and the tight coupling compounds. What was a reasonable shortcut becomes a structural trap. The same principle applies here, but the stakes are higher. A monolith with entombed logic is expensive for human developers. For AI agents, it's a dead end. These are the three specific failure modes I keep running into.
The implicit rules problem
In older systems, business logic accumulates through years of conditional branches that just grew organically. Nobody sat down and wrote, "Here are the rules for eligibility." Instead, a developer in 2009 added an if-else for a new product type. Someone else added another in 2012 for a regulatory change. A third person added a database trigger in 2016 to handle an edge case identified in QA. The rules are real, and they work, but they exist as behavior, not as documentation. A human developer can work with this if they have enough time to read the code. They can reverse-engineer the intent. It's painful but possible.
An AI agent can't do this. An agent needs to call a function, pass arguments, and get a result. But in your code, there is no function to call that says, "Is this discount applicable?" There's just a tangle of conditions that produce the answer as a side effect of running the full transaction. While coding AIs like Gemini or Claude can parse code and infer intent, you don't want your production agent doing that on every call. It's slow, expensive, and fragile. You could make your agent more intelligent by wrapping that logic in a skill or tool your agent can call, essentially writing a translation layer that interprets the entombed behavior and returns a structured result. That works. But now you've got two problems instead of one. You have the original entombed logic, still coupled and untouchable, and a translation layer sitting on top of it that must be maintained whenever the underlying logic changes.
Which it will. Business rules aren't static (remember the accumulation of business logic and organic growth that got us here in the first place)..
Instead, fixing the root cause, actually exposing the logic through a clean, callable interface, means every consumer of that logic, not just your AI agent, benefits. Your integration tests get easier. Your next AI initiative doesn't start from scratch. Your human developers no longer have to reverse-engineer behavior every time they need to touch it. You pay the cost once instead of building a new workaround for every new thing you need to reach.
The dark data problem
When logic is entombed, the data it produces tends to be just as inaccessible as the logic itself. The outputs get written to tables in proprietary schemas that were never designed to be queried from outside the application. Or they live in inconsistent formats across multiple databases that don't agree with each other. Or they're generated in batch processes that run overnight, making real-time access impossible.
I've seen this described as "dark data". It exists, it's valuable, the company paid real money to generate it, but no external system can reliably consume it.
For AI systems that use retrieval-augmented generation, which is most of the practical enterprise AI work happening today, this is a critical failure point. The model is only as good as the context it can retrieve. If the relevant data is in a schema that hasn't been touched since 2008 and has no API layer, the model operates on incomplete information and produces incomplete or incorrect answers. And it does so confidently, which makes it worse.
The coupled side effects problem
This is the one that specifically kills agent workflows. In a tightly coupled system, you can't invoke one piece of logic without triggering the machinery around it. Call the pricing function, and you send an email. Call the eligibility check, and write an audit record. Call the inventory lookup, you fire a UI event that makes no sense in an API context.
AI agents need to be able to *explore*. They need to try options, compare outcomes, and evaluate hypotheticals before committing to a decision. That requires the ability to call functions in a read-only or sandboxed way. A tightly coupled monolith makes this impossible. Every query is also a write. Every read is also a notification. There's no "just tell me the answer without doing anything else."
This is the part that surprises people who haven't built agents before. It's not obvious from the outside why an agent would need to call a pricing function ten times before placing an order. But that's often exactly how they reason — explore the space, evaluate the options, then commit. If each exploration triggers a real-world side effect, you either have to abandon that reasoning style or build an elaborate undo mechanism. Neither is a great answer.
The common thread across all three of these failure modes is that they're not new problems. They're old problems that AI just made significantly more expensive. Entombed logic was always a liability. It just didn't surface as a complete blocker until you tried to connect something to it that couldn't navigate a UI.
Next, I want to talk about what to actually do about it, and more importantly, how to figure out where you actually are before you decide what to do.