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 ...