# Agentic Patterns

> Patterns from "Agentic Design Patterns" (Gulli & Sauco, 2025) applied to CD orchestration and state-machine deployment workflows

- Skill: `lobbi-docs/agentic-patterns-10` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lobbi-docs/agentic-patterns-10`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lobbi-docs/agentic-patterns-10/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Lobbi-Docs (https://skillmd.com/u/lobbi-docs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lobbi-docs/agentic-patterns-10

---


# Agentic Design Patterns — Deployment Pipeline

> Patterns from "Agentic Design Patterns" (Gulli & Sauco, 2025) applied to CD orchestration and state-machine deployment workflows

## Applied Patterns

### Prompt Chaining
**Relevance**: Deployment pipelines are inherently sequential — each stage must succeed before the next begins, making prompt chaining the foundational pattern.
**Current Implementation**: The `start` command triggers a linear pipeline of validate → build → deploy → verify stages, each passing state to the next.
**Enhancement**: Model each stage transition as a structured chain link with explicit input/output schemas. The output of the validate stage (manifest, checksums, env config) becomes the structured prompt input to the build stage, ensuring context is never lost across stage boundaries.

### Planning
**Relevance**: Before initiating a deployment, the orchestrator must devise a strategy that accounts for environment, risk level, rollout type (canary, blue-green, rolling), and SLA windows.
**Current Implementation**: The `orchestrator.md` agent selects deployment strategies, but strategy selection is implicit.
**Enhancement**: Add an explicit planning phase that emits a deployment plan artifact (target envs, rollout %, health check thresholds, estimated duration, rollback triggers) before any execution begins. The plan is approved (by HITL or auto) before the pipeline proceeds.

### Exception Handling
**Relevance**: Deployment failures are not exceptional — they are expected scenarios that require structured recovery, not ad-hoc responses.
**Current Implementation**: The `rollback.md` agent and `rollback` command handle failure recovery; the `validator.md` agent detects issues.
**Enhancement**: Wrap each pipeline stage in a try/catch pattern with typed exception classes: `ValidationError`, `BuildError`, `HealthCheckFailure`, `TimeoutError`. Each exception type maps to a predefined recovery action (retry, rollback, notify, halt). The rollback agent receives the exception type as input context.

### Human-in-the-Loop (HITL)
**Relevance**: Production deployments and rollbacks to critical environments require human authorization gates before proceeding.
**Current Implementation**: The `approve` command provides a manual approval mechanism at the pipeline level.
**Enhancement**: Formalize HITL as a blocking gate with configurable placement: pre-deploy approval, post-canary validation approval, and rollback confirmation. Each gate presents a structured summary (diff, risk score, affected services, estimated impact) and records the approver identity and timestamp in the deployment history.

### Guardrails
**Relevance**: Deployments must enforce hard constraints — never deploy to production without passing health checks, never exceed a change-failure-rate threshold, never skip required approval stages.
**Current Implementation**: The `validator.md` agent checks pre-conditions; the pipeline has validation stages.
**Enhancement**: Extract guardrails into a declarative constraint layer evaluated before and after every stage. Guardrails include: artifact integrity checks, environment drift detection, concurrent deployment prevention (mutex lock), SLA window enforcement, and rollback-eligibility verification. Constraint violations immediately halt the pipeline with a structured error report.

### Goal Setting
**Relevance**: A deployment is successful only when it meets defined SLA targets — latency, error rate, availability — not simply when the deployment command exits 0.
**Current Implementation**: The pipeline tracks deploy status but success/failure is binary (command success vs. failure).
**Enhancement**: Define deployment goals as measurable SLA criteria attached to the pipeline plan. After deploy, the orchestrator evaluates whether goals are met (p99 latency < X ms, error rate < Y%, all health checks green for Z minutes). Only when goals are satisfied does the pipeline transition to `COMPLETE`; otherwise it triggers exception handling.

### Evaluation
**Relevance**: Each deployment run is a data point. Evaluating outcomes over time improves future deployment decisions and detects degrading patterns.
**Current Implementation**: The `history` command surfaces past deployments, but evaluation is manual.
**Enhancement**: After each pipeline completion, emit a structured evaluation report: goal achievement (met/missed/partial), stage durations, rollback count, MTTR for failures, and change-failure rate trend. Store these in the deployment history for trend analysis and use them as context in the planning phase of subsequent deployments.

### Multi-Agent
**Relevance**: Complex deployment workflows exceed the capability of a single agent — orchestration, validation, and rollback are distinct responsibilities requiring specialized agents.
**Current Implementation**: Three specialized agents exist — `orchestrator.md`, `validator.md`, `rollback.md` — with defined roles.
**Enhancement**: Formalize the multi-agent topology with explicit communication contracts: the orchestrator is the sole coordinator; validator and rollback agents are workers that receive structured task requests and return structured results. Add a monitoring agent that runs concurrently during deployment, watching health signals and alerting the orchestrator if guardrail thresholds are approached before they are breached.

## Pattern Interaction Map

```
User Request
    │
    ▼
[Planning] ──────────────────────────────────────────────────────┐
  Emit deployment plan (strategy, goals, guardrails config)       │
    │                                                             │
    ▼                                                             │
[HITL Gate] ← human approves plan                                │
    │                                                             │
    ▼                                                             │
[Prompt Chaining] — stage-by-stage execution                     │
  ├── Stage N input = Stage N-1 structured output                 │
  ├── [Guardrails] checked at every stage boundary               │
  └── [Multi-Agent] Orchestrator ↔ Validator ↔ Monitor agents   │
    │               (concurrent monitoring during execution)      │
    ▼                                                             │
[Exception Handling]                                             │
  ├── Typed exceptions → recovery map                            │
  └── Rollback agent activated with exception context            │
    │                                                             │
    ▼                                                             │
[Goal Setting] — evaluate post-deploy SLA metrics               │
    │                                                             │
    ▼                                                             │
[Evaluation] — emit structured deployment report ←──────────────┘
  Feeds back into Planning context for next deployment
```

## References
- Gulli, A. & Sauco, M. (2025). Agentic Design Patterns.
- Repository: github.com/Mathews-Tom/Agentic-Design-Patterns