Jageshwar Tripathi

 The mistake many BMAD implementations make is putting quality rules inside the workflow. Those rules should exist at three levels: Global Engineering Constitution (all agents) Role-Specific Standards (Architect, UI, Backend, QA, etc.) Definition of Done Gate (executed before agent completion) Below are examples. GLOBAL ENGINEERING CONSTITUTION Add this to EVERY engineering-related agent. engineering_constitution: | ENGINEERING PRINCIPLES The solution must prioritize: - Maintainability over short-term speed - Simplicity over unnecessary abstraction - Readability over clever implementations - Modularity over monolithic structures - Explicitness over hidden behavior - Testability over convenience - Security by design - Scalability by design - Observability by design Before producing any deliverable: 1. Validate assumptions 2. Identify risks 3. Evaluate alternative approaches 4. Select preferred approach 5. Verify against quality checkl...

In the first two posts, I discussed two different execution models for Agentic Systems and why guardrails are much broader than AI safety. The obvious next question is: How do we actually implement guardrails? The answer depends entirely on who controls execution. If your framework controls execution (LangGraph, Semantic Kernel, AutoGen, OpenHands and similar frameworks), many guardrails can be implemented as executable code. If the LLM controls execution (many GitHub Copilot + VS Code agent workflows, BMAD-style frameworks, prompt-based agents), the implementation strategy is very different. This is where many teams struggle. They keep adding more instructions to agent prompts and expect deterministic behavior. Unfortunately, longer prompts do not create stronger guardrails. Instead, think of guardrails as layers. Layer 1 — Prompt Guardrails These are the instructions placed inside agent definitions, skills or shared context. Examples: Never assume missing requirements. Ask clarificat...

In my previous post, I discussed two broad execution models for Agentic Systems: Programmatically Orchestrated Systems – where an application/framework controls execution. Prompt-Orchestrated Systems – where the LLM itself plans and executes based on prompts, agent definitions, skills and workflows. Once you understand this distinction, the next obvious question is: What exactly are Guardrails? Many people equate guardrails with AI safety: Prevent prompt injection Block harmful content Protect secrets Prevent data leakage These are certainly guardrails, but they represent only one category. For Agentic SDLC, guardrails are much broader. Guardrails are constraints, policies, validations, or controls that influence or verify an agent's behavior before, during, or after execution. Think of them across the entire lifecycle. 1. Input Guardrails Applied before execution begins. Examples: Validate that requirements are complete. Detect ambiguous instructions. Require missing acceptance ...

The industry talks about "AI Agents" as if they all work the same way. They don't. Broadly, there are two architectural patterns. Pattern 1: Programmatically Orchestrated Agentic Systems Examples: LangGraph Semantic Kernel AutoGen OpenHands (parts of its execution model) Here, an application orchestrates the execution. The framework decides: which agent runs next when to invoke tools branching and loops retries approval gates state transitions memory management The LLM is primarily responsible for reasoning and generating outputs, but it is not in complete control of the execution flow. A simplified view looks like this: User │ Application / Framework │ Planner │ Developer Agent │ Reviewer Agent │ Tester Agent │ Deploy The framework is deterministic. The LLM participates inside individual steps. Pattern 2: Prompt-Orchestrated Agentic Systems Examples include many VS Code workflows using GitHub Copilot custom agents, BMAD-style agent definitions, prompt ...

 Below is a concise architecture decision table mapping each quality attribute to typical architectural tactics/strategies and concrete solution approaches. This is structured so an architect can derive candidate solutions and design constraints for each goal. Quality Attribute Architectural Tactics / Strategies Typical Solution Approaches / Patterns Key Design & Technology Choices Trade-offs / Risks Availability Redundancy, failover, fault isolation, health monitoring Active-active or active-passive clusters; load balancers; circuit breaker; bulkhead Multi-AZ / multi-region deployment; container orchestration self-healing; health probes Higher cost; data consistency complexity Scalability Horizontal scaling, partitioning, elasticity Stateless services; sharding; event-driven architecture; autoscaling Microservices; message queues/streams; distributed cache; autoscaling groups Operational complexity; distributed data issues Performance Reduce latency, increase throughput, concu...

  1) Simple CRUD or data-centric systems If the core problem is straightforward data storage and retrieval with minimal business rules: Admin dashboards Basic inventory apps Simple reporting tools DDD adds layers (aggregates, repositories, domain services) without real benefit. 👉 Better fit: Transaction scripts, layered architecture, or even low-code. 2) Stable domains with little change DDD shines when: Rules change frequently Language evolves Domain knowledge deepens If the domain is mature and unlikely to change (e.g., fixed regulatory forms, static catalogs), DDD’s modeling effort doesn’t pay off. 3) Small teams or short-lived projects DDD requires: Shared language Modeling workshops Ongoing refinement For: 1–2 developers Proof-of-concepts Hackathons MVPs with uncertain future …the coordination cost exceeds value. 4) When the domain complexity is low but technical complexity is high Example: Real-time streaming...

Scenario Build an Order Management system with: order lifecycle payments shipment cancellations refunds We’ll map roles → inputs → artifacts → outputs → consumers . 1) Roles in AI-era DDD We’ll use these roles: Architect Domain Designer Developer AI Coding Agent QA / Validator AI 2) Step-by-step lifecycle with artifacts Step 1 — Architect defines domain boundaries Architect input business scope enterprise architecture system landscape integration needs Architect produces Bounded Context Map Example: Order Management Payment Shipping Customer Catalog Relationships: Order → uses Payment Order → triggers Shipping Order → reads Catalog Who consumes Domain Designer AI Agent Developers 👉 This tells AI: “don’t mix payment logic into order.” Step 2 — Domain Designer defines ubiquitous language Designer input workshops with business policies terminology lifecycle rules Designer produces Domain Glossary Example: Order: co...