AI App Delivery Top 10: Bespoke application requirements

Lori Mac VittieDistinguished Engineer and Chief Evangelist | F5

Our original ADC09 entry makes a pragmatic observation: not all applications fit neatly into standardized delivery models. Some require custom routing, specialized integrations, or unique handling that falls outside default load balancing and security patterns. The takeaway is equally pragmatic. If you try to force every application into the same mold, you either break the app or create operational drag. The answer has always been programmability in the delivery layer, so you can adapt without rewriting everything.

That premise still holds.

What’s changed is that AI has dramatically increased the number of applications that behave this way. What used to be edge cases are quickly becoming the norm.

AI systems are not static. They are compositional, context-driven, and increasingly autonomous in how they fulfill requests. That means “bespoke” is no longer a characteristic of a few applications. It is a characteristic of the architecture itself.

Consequences of bespoke AI application requirements

Impact on availability

In traditional systems, bespoke requirements often complicated availability because they introduced custom logic into routing and failover. Standard patterns assume predictable behavior. When an application deviates from that, availability strategies have to be adjusted to match.

AI shifts the problem from routing requests to completing decisions.

A request to an AI system is not a simple transaction. It may involve selecting a model, retrieving context, applying policy, generating a response, and potentially invoking additional services or tools. Each of those steps can succeed or fail independently, and each may be subject to different constraints such as latency thresholds, cost limits, or regulatory requirements.

That means availability is no longer just about whether an endpoint is reachable. It is about whether the system can successfully execute the entire chain of decisions required to fulfill the request.

You can have a system where every component is technically healthy, yet the application is unable to produce an answer. A model may be available but disallowed for a given dataset. A retrieval step may return data that cannot be used due to policy. An agent may begin a workflow and be unable to complete it because a required action is blocked.

This creates a different class of availability challenge. Traditional failover assumes you can send the request somewhere else. In AI systems, you often need to find an alternate way to complete the task. That requires dynamic decision-making in the delivery layer, not just redundancy in the infrastructure.

Impact on scalability

The original entry highlights the difficulty of scaling applications that depend on bespoke integrations. Each additional dependency introduces complexity, and scaling often requires additional development effort to manage those integrations effectively. AI amplifies this because it is inherently built on composition.

An AI-driven application may rely on multiple models, vector databases, APIs, and external data sources. The combination of those elements is not fixed. It can change based on the request, the user, or the context. That variability becomes the dominant factor in scalability.

Scaling is no longer just about handling more requests per second. It is about handling more combinations of behavior per request.

If every variation has to be implemented in application code, the system quickly becomes unmanageable. Changes become risky, deployments slow down, and the application turns into a patchwork of conditional logic.

So the same solution for traditional applications becomes even more important. You push that variability out of the application and into the delivery layer. Routing decisions expand into orchestration decisions. Service insertion becomes dynamic composition. The delivery tier becomes responsible for selecting the right combination of components to fulfill each request.

Without that shift, scalability collapses under its own complexity.

Impact on operational efficiency

Bespoke requirements have always increased operational overhead. Each exception requires maintenance. Each customization introduces another point of failure. Over time, that accumulates into a system that is harder to manage and slower to evolve. That’s operational debt, and AI accelerates its accumulation.

The system is no longer just handling predefined paths. It is generating them. Different prompts may trigger different execution paths. Agents may chain together actions in ways that were not explicitly designed ahead of time. New models and services are introduced regularly, each with their own characteristics and constraints.

This creates a constant stream of variation that operations teams have to account for.

If the only way to manage that variation is by modifying application code or updating static configurations, the system becomes brittle. Teams spend their time reacting to edge cases instead of managing the system as a whole. Inconsistencies emerge between environments. Behavior drifts.

Operational efficiency, then, depends on whether you can centralize control over that variability. The delivery layer has to act as a stabilizing force, absorbing differences and enforcing consistent policies across an otherwise dynamic system. Without that, bespoke quickly turns into chaos.

Best practices for managing bespoke requirements

Programmability as a first-class capability

Programmability remains the key to handling bespoke requirements, whether AI, traditional, modern, or <insert next generation here>. Instead of hardcoding logic into applications, you introduce a programmable layer in the delivery path that can adapt to different needs.

With AI, this becomes essential because AI systems evolve quickly. New models are introduced, policies change, data sources shift, and interaction patterns are emergent. You cannot anticipate all of that at design time, and you cannot afford to rebuild applications every time something changes.

A programmable delivery layer allows you to adapt in place. You can inspect requests, apply context-aware routing, modify inputs and outputs, and insert or remove services as needed. More importantly, you can do so consistently across applications.

This is where application delivery starts to look less like plumbing and more like a control plane. It is not just moving traffic. It is shaping how the system behaves.

Traffic steering becomes decision routing

Traditional application delivery focuses on directing traffic to the right destination. The question has always been “where should this request go?” AI changes that question into something more nuanced, “What is the best way to fulfill this request?”

Sometimes that means selecting between multiple models based on latency, cost, or compliance requirements. Sometimes it means enriching the request with additional context before sending it to a model. Sometimes it means bypassing AI entirely and routing to a deterministic service that can provide a more accurate or compliant answer.

The decision is no longer just about location. It is about execution.

That shift turns routing into a higher-level function. It becomes responsible for selecting the path the request will take through a set of possible capabilities. It also means the delivery layer needs visibility into more than just network conditions. It needs awareness of policies, context, and desired outcomes.

This is a natural extension of what ADC09 has always argued. When applications have unique requirements, the delivery layer has to adapt. AI simply raises the level at which that adaptation occurs.

Conclusion

Programmability as a capability has always acknowledged a simple truth: applications are not uniform, and infrastructure has to accommodate their differences. That truth remains unchanged.

What AI does is increase both the frequency and the complexity of those differences. Systems become more dynamic, more compositional, and more dependent on runtime decisions. The idea of a “standard” application path becomes harder to sustain.

The response is the same as it has always been, but more urgent.

You need programmability in the delivery layer. You need centralized control over how requests are handled, routed, and fulfilled. And you need the ability to adapt to new requirements without rewriting applications every time something changes.

Because in an AI-driven architecture, bespoke is no longer an exception you design around.

It is the operating model you design for.

Read more about the Top 10 Application Delivery challenges faced by organizations across the globe.

About the Author

Lori Mac VittieDistinguished Engineer and Chief Evangelist | F5

Lori MacVittie is a Distinguished Engineer and Chief Evangelist in F5’s Office of the CTO with deep expertise in application delivery, automation strategy, and infrastructure. She is known for turning complexity into clarity whether she’s defining guardrails for AI agents, dissecting brittle multicloud architectures, or probing the limits of scalable systems. She brings more than thirty years of industry experience across application development, IT architecture, and network and systems operations. Before joining F5, she served as an award-winning technology editor. MacVittie holds an M.S. in Computer Science and is a prolific author whose publications span security, cloud, and enterprise architecture. She is also an avid tabletop and video gamer with unapologetically strong opinions about cheese.

More blogs by Lori Mac Vittie