Design Agentic AI Backwards: Start With Constraints, Not Tools

The Wrong Way to Build Agentic AI

Many developers approach agentic AI system design backward. They start by asking about specific tools: Which Large Language Model (LLM) should we use? Should we integrate LangGraph? Where does MCP fit? Do we need RAG (Retrieval-Augmented Generation)? Should we build multiple agents, and should each step be handled by an autonomous agent? These are valid questions, but asking them too early leads to architectures that are technically complex but suffer from operational issues: high costs, slow performance, and a surprising lack of trustworthiness.

This common pitfall results in systems that prioritize impressive tooling over core functionality. The focus shifts to demonstrating technical capability rather than solving a user problem reliably and efficiently. The result is often a system that looks good on paper but fails in practice when faced with real-world demands for speed, cost-effectiveness, and dependable output.

The LCFE Framework: Constraints First

A more effective approach reverses this order: start with the desired product outcome, meticulously define the constraints, and then design the architecture. The choice of tools should be the last step. This method ensures that the system is built with purpose and practicality at its core.

To structure these constraints, consider the LCFE framework: Latency, Cost, Functionality, and Execution.

L — Latency

Latency is the time it takes for the system to produce an output. For agentic AI, this is often measured from the moment a user request is made to the moment a satisfactory response is delivered. High latency can cripple user experience, especially in interactive applications. Think of a customer support bot that takes minutes to answer a simple query; users will abandon it. Conversely, real-time applications, like co-pilots for coding or interactive creative tools, demand near-instantaneous responses.

When defining latency constraints, be specific. Instead of "fast," aim for "under 5 seconds for 90% of queries" or "real-time interaction suitable for live chat." This precision informs tool selection. For instance, if sub-second latency is critical, you might rule out LLMs with high inference times or complex multi-agent orchestrations that add processing delays. You might prioritize smaller, faster models or optimize RAG pipelines for speed.

C — Cost

Cost encompasses all expenses associated with running the agentic AI system. This includes API calls to LLMs, hosting infrastructure, data storage, and developer time for maintenance and iteration. Agentic systems, with their potential for complex chains of calls and multiple agent interactions, can become surprisingly expensive.

A clear cost constraint helps manage these expenses proactively. Questions to ask include: What is the target cost per user interaction? What is the maximum operational budget? If a system needs to handle millions of users daily, even a few cents per interaction can balloon into millions in monthly costs. This constraint might lead you to explore fine-tuning smaller models, implementing caching strategies, or using cheaper, task-specific models for certain agent functions instead of relying solely on a single, powerful, but expensive general-purpose LLM.

F — Functionality

Functionality defines what the agentic AI system must actually *do*. This is about the core capabilities and the desired quality of the output. What specific tasks must it accomplish? What level of accuracy, creativity, or reasoning is required? This is where you define the problem the AI is solving.

For example, a system designed to summarize legal documents needs high accuracy and a deep understanding of legal jargon. An agent tasked with generating marketing copy might prioritize creativity and brand voice adherence over absolute factual precision. Understanding these functional requirements guides the choice of LLM capabilities, the need for specialized knowledge bases (RAG), and the complexity of the agent's reasoning process. If the functionality requires highly specialized knowledge, a RAG system becomes almost mandatory, irrespective of other constraints.