Why AI Projects Fail Beyond the Model

AI projects often falter due to shortcomings in the surrounding infrastructure rather than the core AI model's performance. The primary causes of failure typically involve issues with data integrity, contextual relevance, seamless integrations, robust security, and cost management. These 'unglamorous' aspects are frequently omitted from initial demonstrations, which focus solely on the model's capabilities, creating a misleading perception of readiness.

Bridging the gap between an exciting AI idea and its real-world impact requires structured architectural thinking that accounts for every component of the system. Without this holistic approach, projects struggle to scale, remain reliable, and ultimately fail to deliver on their promise in a production environment.

Safeena Banu, Principal Technical Evangelist at Elsevier, noted that the model itself rarely fails. She stated, "What failed was everything around the model, the data, the context and the integrations, security, cost, governance. Whether a real person could actually use those things, all the unglamorous parts nobody put on those slide with the demo."

Transitioning AI from simple experimentation to a production environment demands a fundamental mindset shift, especially regarding error handling and scalability. Initial simplicity in development often conceals significant complexities that emerge downstream, requiring a proactive architectural approach.

Correcting these architectural mistakes early in the development cycle is substantially more cost-effective than attempting late-stage refactoring. Safeena Banu emphasized this point, stating that her team learned these lessons "the hard way" in real-world applications.

Early iterations, while seemingly ground-breaking, functioned as simple 'magic' demonstrations rather than robust systems.

Scaling these solutions required a shift to multi-agent systems capable of navigating complex, multi-task environments. The current architecture includes specialized agents for planning, authoring, healing, and monitoring, ensuring the system's resilience and effectiveness in production.

This stack incorporates technologies like Playwright, Behavior-Driven Development (BDD), and TypeScript to manage various tasks.

The system includes a Feature Planner, a Locator Inspector, and a Quality Reviewer, each serving a distinct purpose in the QA process. It uses a Model Context Protocol (MCP) to integrate with tools like Jira and Playwright.

A crucial design principle is the separation of model-based reasoning from deterministic code execution. For instance, the Locator Inspector, a sub-agent, performs live inspections of web pages, which the main agent then uses for further planning, as Safeena Banu detailed: "Feature planner calls locator inspector. This is the sub agent. This is the main agent. All of these are sub agents. The locator inspector goes, does live inspection of the page."

Sub-agents, such as the locator inspector, perform specific tasks like inspecting elements on a page.

Once the locator inspection is complete, the task is handed off to another sub-agent, the feature planner, responsible for writing BDD scenarios and step definitions. This modularity enhances observability, allowing users to trace the actions of individual sub-agents, as Safeena Banu pointed out: "The advantages is that you get to see the sub agents... this locator inspector is a sub agent which gets called first... once the locator inspection finishes it hands off to the feature planner."

The development team invested significant effort into building this architectural layer, which dictates prohibited actions and integrates past review comments to enhance test quality.

This contextual layer ensures that tests are not only effective but also adhere to established quality standards and security protocols. A quality review gate serves as the final validation step, checking against predefined rules and security requirements before deployment, preventing known issues from recurring. As Safeena Banu explained, "We spent a lot of time building the whole architectural layer, the contextual layer where we say these are the things you should not do. These are the review comments, the previous review comments from the tests."

These goal-based systems inherently involve probabilistic components, which significantly add to their complexity.

Developers must meticulously account for potential failure modes at every point of interaction and integration. This complexity arises from managing interconnected components and their uncertain behaviors, requiring a more robust architectural approach than traditional AI development methods. Safeena Banu emphasized, "You're no longer prompt engineering; you are building a distributed system with a probabilistic component, which adds the complexity over here."

A common initial mistake in AI development is providing models with an excessive amount of context, which leads to 'context bloat' and ultimately 'context poisoning'. This over-provisioning of information degrades model performance as irrelevant data introduces noise and makes the model less efficient.

Model performance drifts significantly when extraneous context is continuously fed into the system, diluting the relevance of critical information. To counteract this, it is essential to strictly prune information, providing only the exact amount of context needed for specific tasks. Safeena Banu noted, "Initially, we were like, okay, let's give it all the context. Let's give it everything, and all that which resulted in something called context bloat, which also leads to context poisoning later on."

Utilizing smaller, specialized models for sub-agents can significantly reduce costs and prevent context poisoning, as each sub-agent maintains its own context window, preventing the main agent from being overwhelmed with snapshots.

Control flow delegation should only occur when the return on investment (ROI) clearly justifies the added architectural complexity. Roles should be split among agents only if there are distinct differences in their context requirements, permission sets, evaluation criteria, and failure domains. Safeena Banu stated, "So this sub agent has their own context window; you're not flooding the main agent context, which is run by opus, from all of the snapshots... split a role only when context permissions evaluation surface and failure domain all differ." Viewing multi-agent systems as a cost, rather than an achievement, helps ensure their strategic implementation.

Access to these tools should be treated as an API contract, clearly defining what the model can and cannot do. Safeena Banu advised to "treat it like an API contract and give it everything it needs and just extract what you need."

Configuration files or hooks must explicitly define permitted and forbidden file access, rather than relying on natural language instructions. Developers should avoid using 'star' imports, instead granting the model only the specific tools absolutely necessary for its assigned task to minimize potential security risks and ensure controlled interactions.

Flooding a model with excessive context rapidly makes the system both expensive and unexplainable, as Safeena Banu described it as "the fastest way to make an agentic system both expensive and unexplainable."

It is critical to distinguish between a shared source of truth and a shared context window; the latter is a finite resource that must be managed carefully. Recommendations include compacting context or initiating new sessions once the context window exceeds 50-60% capacity to maintain efficiency and explainability.

This memory should be structured, for example, stored in repository Markdown files, to effectively retain records of past repairs and incidents.

Structured memory allows agents to self-learn from previous errors, preventing the recurrence of known issues. The design of this memory system must be carefully considered, based on factors like access frequency and specific retrieval needs to ensure efficient and effective knowledge accumulation. Safeena Banu highlighted the importance, stating, "It is most important for an agent to self-learn from the mistakes so that it doesn't repeat and you don't repeat the mistakes."

The level of autonomy delegated to an AI system must be a deliberate policy decision, rather than solely based on the model's inherent capabilities. This decision-making framework, often referred to as managing the 'blast radius,' categorizes actions by their reversibility and potential impact.

Read operations, for instance, are generally recoverable and carry lower risks compared to write operations, which alter the system's state and therefore entail higher risks. Safeena Banu emphasized this by saying, "The more irreversible the action, the less autonomy you delegate, and that is a policy decision, not the model decision."

Consequently, the more irreversible an action is, the less autonomy the AI agent should be granted. This policy-driven approach ensures that human oversight remains proportional to the potential consequences of the AI's actions.

Using a lower-cost model in an important step can lead to an increase in token usage as the model may generate excessive questions and suboptimal results. Safeena Banu illustrated this by saying, "Imagine you're using a cheaper model in a decision step or an important step. There you will lose more tokens because it'll keep asking 100 questions and it'll keep generating the result which is not good."

This inefficiency can degrade overall system performance and ultimately result in paying the same or even higher costs than with more powerful, initially expensive models. Effective decision steps require reliable, high-performing models to avoid such performance degradation.

Organizations should evaluate cost-per-transaction, including all model calls and retries, rather than just the per-token cost. Outcome-based testing should be used to compare smaller models against frontier models, ensuring that the chosen model delivers optimal value and efficiency.

These critical factors must be embedded into the design process from the very beginning. Safeena Banu clearly stated, "Cost and latency are architecture decisions. They are not a bill. So they're decided upfront."

To manage these, designers should determine various reasoning levels (high, medium, low) to control resource usage and optimize workflows. Identifying patterns from existing research can further refine these optimizations. Additionally, implementing audit trails and kill switches is essential to maintain control and ensure stability in production environments.

The ultimate goal is not the most autonomous system, but rather the least autonomous system that consistently achieves the desired outcome and can gracefully recover from errors.

Systems must be intentionally designed to survive being wrong, incorporating robust error handling and recovery mechanisms. This ensures resilience and trustworthiness in real-world applications. Safeena Banu emphasized, "The goal is not the most autonomous system. Trust me, it's the least autonomous system that creates the outcome you need and can survive being wrong."

Crucially, if a layer within the AI system lacks a clearly defined contract, owner, failure mode, and success metric, it is not deemed ready for production. These foundational elements are essential for accountability, predictability, and maintainability.