Skip to main content

Guardrails for AI Native SDLC - Two architectural patterns


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 libraries, skills, and markdown-based workflows.

What appears to be:

  • Agent

  • Skill

  • Workflow

  • Persona

  • Checklist

is often implemented as prompt context supplied to the LLM.

The execution is closer to:

User Prompt
        +
Agent Instructions
        +
Workflow Instructions
        +
Skills
        +
Context Files
        ↓
      LLM
        ↓
Reasoning
        ↓
Tool Usage
        ↓
Response

The LLM is simultaneously:

  • planner

  • controller

  • executor

  • reviewer (if instructed)

  • tool user

There is usually no external engine enforcing that Step 1 must complete before Step 2, or that every checklist item must be followed. The LLM is expected to follow the instructions, but it can also skip, reorder, or partially apply them.

This distinction is important.

Many teams believe they have built a deterministic workflow because they have "agents" and "skills." In reality, they have built a sophisticated prompt that relies on the LLM to faithfully execute it.

That doesn't make it a bad approach. It simply means the engineering challenges are different.

In deterministic frameworks, guardrails are often implemented as executable code and policy.

In prompt-orchestrated systems, guardrails are largely behavioral instructions unless backed by external validation.

Understanding which architecture you're building is the first step toward designing effective Agentic SDLC guardrails.

In the next post, we'll look at what guardrails actually are, the different types of guardrails, and why the implementation strategy is fundamentally different between deterministic frameworks and prompt-orchestrated systems.

Comments

Popular posts from this blog

Example 1: ArchiMate relationship in PlantUML code to demonstrate 15 relationship types

 Following section presents 15 types of relationships in ArchiMate and PlantUML to generate the diagram. Since this code is generated by GEN-AI it may require precision on aspects other than PlantUML syntax: Diagram Plant UML Code:  @startuml '!includeurl https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/Archimate.puml ' Another way of including Archimate Library (above is commented for following) !include <archimate/Archimate> !theme archimate-standard from https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/themes title ArchiMate Relationships Overview <style> element{     HorizontalAlignment: left;     MinimumWidth : 180;     Padding: 25; } </style> left to right direction rectangle Other {     Business_Role(Role_SeniorManager, "Senior Manager")     Business_Role(Role_Manager, "Manager") } rectangle Dynamic {     Business_Event(Event_CustomerReques...

Examples 7: ArchiMate flow relationship between elements in layers

Diagram Code @startuml !include < archimate / Archimate > < style > element {     HorizontalAlignment : left ;     MinimumWidth : 180 ;     Padding : 20 ; } note {     BackgroundColor : #FFFFCC ;     RoundCorner : 5 ;     MaximumWidth : 250 ; } </ style > title "ArchiMate 3.2 Valid Flow Relationships" left to right direction ' Business Layer Flow Relationships rectangle "Business Layer Flows" {     Business_Process ( bp1 , "Order Process" )     Business_Process ( bp2 , "Payment Process" )     Rel_Flow ( bp1 , bp2 , "Order data" )     note on link         Flow between Business Processes     end note         Business_Function ( bf1 , "Sales Function" )     Business_Function ( bf2 , "Delivery Function" )     Rel_Flow ( bf1 , bf2 , "Sales information" )     note on link     ...

Mastering Trade-Off Analysis in System Architecture: A Strategic Guide for Architects

 In system architecture and design, balancing conflicting system qualities is both an art and a science. Trade-off analysis is a strategic evaluation process that enables architects to make informed decisions that align with business goals and technical constraints. By prioritizing essential system attributes while acknowledging inevitable compromises, architects can craft resilient and efficient solutions. This enhanced guide provides actionable insights and recommendations for architects aiming to master trade-off analysis for impactful architectural decisions. 1. Understanding Trade-Off Analysis Trade-off analysis involves identifying and evaluating the conflicting requirements and design decisions within a system. Architects must balance critical aspects like performance, scalability, cost, security, and maintainability. Since no system can be optimized for every quality simultaneously, prioritization based on project goals is essential. Actionable Insights: Define key quality ...