{
  "id": 3601335,
  "title": "Stop Designing Agentic AI Systems Backwards: Start With Constraints, Then Choose the Architecture",
  "url": "https://urgent.news/2026/08/26/stop-designing-agentic-ai-systems-backwards-start-with-constraints",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-26T21:51:56.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/himanjan/stop-designing-agentic-ai-systems-backwards-start-with-constraints-then-choose-the-architecture-5125"
  },
  "original_language": "en",
  "account": "When designing agentic AI systems, it is common to ask questions about which LLM to use, how to implement MLOps, and whether to utilize various techniques like Retrieval Augmented Generation (RAG). However, these questions are often asked too early in the development process. This can lead to an architecture that is technically impressive but operationally difficult, expensive, slow, and hard to trust. A better approach is to reverse the order of these questions. Begin with the desired product outcome, establish constraints, and then design the architecture. Choose the tools last.\n\nConstraints can be organized around four dimensions: Latency (L), Cost (C), Failure (F), and Evaluation (E). By focusing on these constraints, we can create a more practical and reliable system. For instance, consider an AI Incident Resolution Assistant for an engineering organization. The goal is to resolve common production incidents within 10 minutes while reducing manual engineer effort and keeping high-risk actions under human approval.\n\nTo start with constraints, ask questions such as: What is the acceptable P95 time to initial diagnosis? What is the maximum cost per incident? What happens when a failure occurs? And how do we evaluate the system's effectiveness? By defining these constraints, we can make more informed decisions about the architecture and tools required.\n\nA backward design process reveals that not every incident needs an autonomous agent. By analyzing historical incident data, we can identify patterns and create deterministic workflows for common incidents. This simplifies the architecture and reduces the need for multiple autonomous agents, unnecessary memory, and multiple reasoning loops.\n\nApplying these constraints leads to a new architecture where the system is more production-oriented. The system begins with a fast classifier to determine whether an incident is known or unknown. For known incidents, a deterministic workflow is followed. For complex or unknown incidents, an agent is utilized for investigation and remediation. High-risk actions are subject to human approval, while safe remediation actions are automated.\n\nBy starting with constraints and defining the product outcome, we can create a more practical, reliable, and cost-effective agentic AI system. This approach ensures that technology decisions are made based on the realities of the product rather than the capabilities of the underlying tools.",
  "summary": "There is a pattern I keep seeing when designing Agentic AI systems. We start by asking: Which LLM should we use? Should we use LangGraph? Where can MCP fit? Should we build multiple agents? Do we need RAG? Should we add memory? Should every step be handled by an autonomous agent? These are useful questions. But they are often asked too early . The result can be an architecture that is technically…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}