Modularity and Component Design in AI Applications

Imagine you have built an application that sends user requests to a foundation model and returns the model's answers. It works well in your tests. Then, a few weeks after launch, users start reporting responses that seem wrong, slow, or unsafe. The first question is not how to fix the problem. The first question is how you would have known about it at all. Could you see that something had gone wrong, find where it went wrong, and tell the difference between a single odd answer and a real pattern?

This article follows that question step by step. You will watch a failure move through the components of an AI application, see how it can be made detectable and traceable, and learn why every added component brings new ways to fail. The idea that answers the question is called observability, and it asks you to think about failure before failure happens.

An AI application is usually separated into components, and each component has a clear job that you can reason about on its own. The boundaries between components are rarely as clean as a diagram suggests, but a simplified chain is enough to trace how a fault spreads. In the example below, which is an illustrative design rather than a fixed architecture, a request passes through a retriever, a prompt builder, a model call, and a guardrail before the answer reaches the user.

Suppose the retriever returns documents that do not match the question. The prompt builder does not check the relevance of those documents; it assembles a prompt from what it receives. The model call then produces an answer grounded in the wrong material. Nothing in that chain necessarily raises an error, so the bad output first becomes visible at the end of the chain, to the user, unless something upstream recorded what happened. The place where a failure starts and the place where it is seen can be far apart. That gap is the central problem observability is designed to close.

The definition has three parts, and they depend on one another. The parts are worth taking in order, because each one relies on the one before it.

A system with excellent dashboards but no way to connect a bad answer to the request that produced it is only partly observable. The dashboards may show that something changed, but without the trail, a team cannot find out which request and which step were responsible.

Much of what you already know about monitoring software applies here too. Software engineering has long offered practices for logging, tracing requests, watching resource use, and paging someone when a service degrades. Traditional machine learning has its own practices for tracking model behavior over time. You should reuse these tools rather than reinvent them.

The difficulty is that foundation models introduce failure modes that those existing practices were not built to catch. The model's behavior is produced by the model rather than written line by line by your team, so the ways it can misbehave do not always match the failures your existing dashboards were designed to show. The metrics you already collect may be necessary but not sufficient, and you will need additional metrics and design decisions aimed at the failures a foundation model can cause.

Traceability depends on what the system records while it is handling a request. The sequence below shows an illustrative order of events in a system designed for observability. A user sends a request, the application calls the model, and the answer returns. Along the way, the application writes records to a telemetry store, so that a failing step can be located after the fact.

The order matters. The telemetry records are written during the request, not reconstructed afterward from memory. If the record of the request and its component calls exists, a team can start from a complaint and move backward to the step that failed. If the record does not exist, the bad answer is only a complaint, and it cannot be connected to anything the system did.

Separating an AI application into components keeps the system easier to change and to maintain. Each component can also be reasoned about on its own. But each addition changes the set of places where things can go wrong. A retrieval step, a tool call, or a guardrail added to a model-only system each brings its own failure points, along with the benefits it was meant to provide.

A guardrail is a good illustration. It is a check that screens what goes into or comes out of a model, for example to block content you do not want the application to produce. A guardrail can be implemented in the inference service that runs the model, in the model gateway that routes requests, or as a standalone component of its own. The job stays the same in all three cases. What changes is where the check lives and which other parts of the system must know about it.

Placement matters for observability. If the check is buried inside the inference service, its decisions may be visible only in that service's records. If it is a standalone component, it can report its own measurements separately, but you now have one more piece to monitor and one more place where things can go wrong. Either way, the guardrail adds failure points of its own, such as blocking an answer that was acceptable or letting through one that was not. Those are generated examples of the kind of failure a team should plan for, not outcomes stated in the source.

You cannot design useful metrics and alerts until you know which failures matter for your application. Identifying the failure modes comes first, and the records, metrics, and alerts follow from them. An alert is useful only when it is tied to a metric that matters, and a metric is useful only when the system actually produces the information it measures.

The map above is a generated illustration of the method, not a fixed list. Each failure mode from the launch scenario is paired with a signal that would reveal it, and each signal is assigned to the component that produces it. Notice that the metrics follow from the failure modes. Starting from the dashboards and asking what they show would invert the order the source recommends.