Why Agentic Systems Fail Without Structure
How to build structural priors for LLMs and avoid the spaghetti code trap.
If you have ever watched an autonomous AI agent try to refactor a legacy codebase, you know the pain. I have been facing this challenge daily because my company, Wangari Global, automates complex financial and ESG reporting workflows. The fundamental problem we solve is the tension between the efficiency of Large Language Models (LLMs) and the strict compliance requirements of regulated industries.
LLMs are probabilistic engines designed to generate plausible text, not deterministic calculators designed to guarantee truth. In finance and insurance, a single hallucinated number or fabricated regulatory interpretation can lead to severe compliance failures. We cannot simply prompt an LLM to “analyze this data and write a report.” We need a fundamentally different architecture.
The Spaghetti Code Trap
The core observation from recent agentic engineering failures is simple: if your codebase has no consistent patterns, agents cannot infer them. (This human-written article explains it much better than I do — it’s behind the Medium paywall, though you can get some free reads.)
LLMs rely entirely on pattern inference. They are statistical engines that predict the next token based on the context they are given. When you deploy an agent into a messy system—a historical jambalaya of library preferences, inconsistent API wrappers, and varying coding styles—you destroy the patterns the LLM needs to function.
Let’s say your project uses both fetch and Axios for API calls, and throws in some TanStack for good measure. Will your next generated API call use fetch or Axios? Who knows? The agent’s behavior becomes stochastic. It might generate a pile of sort-of-working stuff, but it won’t be consistent, and it certainly won’t be reliable.
This is the spaghetti code trap. The messier your existing code is, the less effective your agents will be, and your technical debt will compound like never before.
The Need for Structural Priors
To solve this, we need to introduce a concept that is well-known in machine learning but often ignored in agentic engineering: structural priors.
In machine learning, an inductive bias (or prior) is a set of assumptions that the learning algorithm uses to predict outputs for inputs it has not encountered. In Bayesian inference, priors represent our beliefs about a parameter before we see the data. In distributed systems, architecture constraints ensure that components interact predictably.
Agentic systems require structural priors. We must impose constraints on the LLM to guide its inference and ensure deterministic behavior.
Examples of structural priors include:
Consistent APIs
Schema-first design
Typed interfaces
Deterministic pipelines
Causal graphs
Building a Deterministic Pipeline
At Wangari Global, we use a “deterministic-first” architecture to impose structural priors on our agentic workflows. Instead of asking an AI to act as an autonomous analyst, we deploy AI strictly as a communication layer.
Here is how we structure a deterministic pipeline conceptually:
Calculating the Facts: Traditional, auditable code processes raw data and computes core financial figures deterministically. The LLM does not do math.
Organizing the Metrics: Verified figures are structured into a machine-readable format, such as a strict JSON schema.
Issuing Clear Instructions: The AI receives a strict template and the verified data, with explicit instructions not to add external information. We use low temperature settings to reduce variance.
Writing the Narrative: The AI translates the verified numbers into clear, human-readable prose.
Final Review: An automated process checks every number in the generated text against the original verified dataset, rejecting any output with discrepancies.
The Causal Connection
This concept of structural priors is exactly why causal systems work. They impose structure on inference.
Consider the difference between naive machine learning and structured causal inference. In naive inference, a model infers patterns from messy data without understanding the underlying structure. It might find a correlation between ice cream sales and shark attacks, but it doesn’t know that summer heat is the hidden confounder driving both.
In structured causal inference, we impose a structural prior—a causal graph or Directed Acyclic Graph (DAG)—to guide the estimation.
# Structured causal inference
# We impose a structural prior (the causal DAG) to guide the estimation.
estimate_effect(
treatment="water_recycling",
outcome="water_consumption",
graph=causal_dag
)By letting the data speak through causal graphs, we give our human decision-makers the clarity they need to govern the agents effectively. We move from asking “what happened?” to “why did it happen, and what if we change it?”
If you want to deploy autonomous agents in a regulated environment, you cannot rely on the magic of the model. You must build structural priors into your architecture. By separating the calculation of facts from the generation of narrative, and enforcing an automated review layer, we can harness the power of LLMs without exposing our organizations to unacceptable regulatory risk.
We don’t need the AI to be an analyst; we just need it to be a very reliable translator. And to do that, we must give it the structure it needs to succeed.
More on the Spaghetti Code Trap
Let’s delve deeper into why the spaghetti code trap is so pernicious. When we talk about “messy code,” we often think of it as a human problem—it’s hard for developers to read, maintain, and extend. But for an LLM, messy code is an epistemological problem.
LLMs are essentially highly sophisticated pattern-matching engines. They learn the statistical distribution of tokens in their training data and use that to predict the next token in a sequence. When you provide an LLM with a prompt, you are essentially giving it a starting point and asking it to continue the pattern.
If your codebase is consistent—if it uses the same naming conventions, the same architectural patterns, the same libraries—the LLM can easily infer the pattern and generate code that fits seamlessly into your project. But if your codebase is a mess, the LLM has no clear pattern to follow. It might pick up on a pattern from one part of the codebase and apply it to another, resulting in inconsistent and buggy code.
This is why agentic engineering often fails in legacy systems. The agents are trying to build on a foundation of sand. They are trying to infer patterns where none exist. And the result is exactly what you would expect: a stochastic mess.
The Role of Inductive Bias
To understand how to fix this, we need to look at the concept of inductive bias in machine learning. Inductive bias refers to the set of assumptions that a learning algorithm uses to predict outputs for inputs it has not encountered.
For example, a linear regression model has a strong inductive bias: it assumes that the relationship between the input variables and the output variable is linear. A decision tree has a different inductive bias: it assumes that the relationship can be modeled as a series of hierarchical decisions.
LLMs have a very weak inductive bias. They are designed to be general-purpose pattern matchers, capable of learning almost any pattern if given enough data. This is what makes them so powerful, but it is also what makes them so fragile. Without a strong inductive bias, they are easily confused by noise and inconsistency.
When we impose structural priors on an LLM, we are essentially giving it an inductive bias. We are telling it, “Assume that the code should follow this specific pattern.” This constrains the LLM’s search space and makes its output much more predictable and reliable.
Implementing Structural Priors in Practice
So, how do we implement structural priors in practice? It requires a shift in how we think about software architecture.
Instead of building monolithic applications where everything is tightly coupled, we need to build modular systems with clear, well-defined interfaces. We need to use schema-first design, where the data structures are defined upfront and strictly enforced. We need to use typed languages, where the compiler can catch errors before the code is even run.
And most importantly, we need to build deterministic pipelines. As I mentioned earlier, a deterministic pipeline separates the calculation of facts from the generation of narrative. It ensures that the core logic of the application is handled by traditional, auditable code, while the LLM is relegated to the role of a communication layer.
This approach requires more upfront engineering effort, but it pays off in the long run. It makes the system much more robust, much easier to maintain, and much less prone to the kind of catastrophic failures that can occur when an autonomous agent goes rogue.
The Future of Agentic Engineering
As we move further into the era of agentic engineering, the importance of structural priors will only grow. We are already seeing the limits of what can be achieved with raw LLM power alone. The next wave of innovation will come from combining LLMs with structured, deterministic systems.
This is the core philosophy behind Wangari Global. We believe that the true power of AI lies not in its ability to generate code or text, but in its ability to help humans make better decisions. And to do that, we need systems that are reliable, auditable, and transparent.
We need systems that are built on a foundation of solid engineering principles, not just the magic of the model. We need systems that embrace the power of structural priors.
In the end, agentic AI is just a tool. It is a very powerful tool, but it is still just a tool. It is up to us, the engineers and architects, to use it responsibly. And that means building systems that are designed for reliability, not just speed. It means embracing the discipline of structural priors and rejecting the chaos of the spaghetti code trap.