Manifesto
ADLC Manifesto
Building agentic systems with method, governance, and clarity.
The ADLC manifesto defines common principles for designing governed, tool-agnostic agentic systems driven by an explicit lifecycle.
ADLC Manifesto
Principles for governed agentic software development
SDLC and ADLC: continuity and evolution
ADLC does not replace SDLC: it preserves its engineering practices and extends them to govern software developed with agents and agentic systems in production.
Scope of Application
ADLC applies both to software developed with agent assistance and to systems that use agents in production.
In the first case, it governs generated changes, verification against requirements, and human accountability for acceptance. In the second, it extends these controls to runtime behavior, knowledge, tools, and agent autonomy.
It is not synonymous with autonomous coding or merely securing AI-generated code: it requires verifiable evidence and explicit accountability throughout the lifecycle.
Open Source Repository
The ADLC Manifesto source, license, contribution guidelines, and website files are available in the public repository.
Principles
Five principles to guide every decision
Start from validated requirements
Every initiative starts from requirements that are verified, understandable, and mature enough to reduce ambiguity and rework.
Ensure reuse and orchestration
Components, agents, and capabilities should be designed to be reused, connected, and orchestrated over time.
Remain independent from tools
Tools help, but they should not dictate the architecture: process and governance come before the tool.
Choose the simplest effective solution
Not every problem requires an agent, and more agents do not necessarily produce better results. Choose the least complex solution that meets the approved requirements, granting only the autonomy needed. Justify additional complexity with measurable benefits over a simpler solution.
Grant autonomy on evidence
Permissions, approvals, budgets, and stop controls are enforced at runtime, not only described in prompts.
Governance Guardrails
Controls that are mandatory to enter and govern the ADLC
Human in the Loop
Human oversight is a mandatory control layer in the ADLC (Agentic Development Lifecycle), especially when approving requirements, validating quality, authorizing releases, and governing production behavior.
Agents accelerate and structure the work, but accountable human decisions remain explicit at the critical checkpoints.
Competent oversight, not rubber-stamp approval.
Reviewers must be trained in the domain, agent limitations, and decision risks, with risk-proportionate exercises on errors and incidents. They need accessible evidence, sources, uncertainties, and action consequences, plus enough time and a manageable workload to assess them.
They must have the authority to challenge, reject, pause, request revision, and escalate. Formal approval without substantive verification is not a governance control.
Requirements Quality Gate
No implementation starts without a passed requirements quality gate. The gate approves the next increment, not every future requirement. A quality gate agent may support preparation; accountable humans approve scope, measurable outcomes, risks, and known uncertainties.
This gate is fundamental because it determines whether implementation should begin at all.
Knowledge Governance
The ADLC treats knowledge and context as governed parts of the system. Documents, prompts, shared skills, memory, policies, examples, tool instructions, and information retrieved through RAG, where used, can influence agent behavior and introduce silent regressions even when no application code changes.
Knowledge Governance applies regardless of how context is supplied. Retrieval-augmented generation (RAG) is one technique, not a required architecture or a synonym for knowledge governance. Where used, it requires specific controls for retrieval quality, source freshness, access permissions, and citations.
Knowledge changes must therefore be reviewed, versioned, traceable, and validated against expected behavior before they are used in production.
Runtime context and memory require provenance, permitted writers, retention, user and tenant isolation, deletion, and contradiction handling. Retrieved content cannot grant authority. Compression must preserve permissions, constraints, and decision-critical evidence.
Distributed enterprise context, governed access. Agents must be able to discover and use relevant information through interoperable interfaces, such as APIs, MCP, or equivalent mechanisms. Sources retain ownership, versions, provenance, and access permissions. Context must be selected for the task, and its contribution to output quality must be evaluated.
FAIR · W3C DCAT 3 · W3C PROV-DM. These references support discoverability, interoperability, and provenance; they do not by themselves guarantee better agent outputs.
Explicit Autonomy Contract
Define an accountable owner, permitted actions and data, delegated authority, budgets, stopping conditions, and escalation. Enforce permissions and approvals outside the prompt, with revocable credentials and a tested stop mechanism.
Measurable Behavior and Value
Use representative, versioned datasets, repeated trials, isolated state, and risk-based thresholds. Verify actual outcomes and policy compliance; calibrate model-based graders against human judgment and disclose uncertainty and coverage gaps.
Measure cost per successful task, latency, intervention, rework, escalation, and business value against a baseline. Evidence may justify reducing autonomy or retiring a system.
Stage 0
Requirements Quality Gate
No implementation starts without a passed requirements quality gate. The gate approves the next increment, not every future requirement. A quality gate agent may support preparation; accountable humans approve scope, measurable outcomes, risks, and known uncertainties.
Use the least autonomy and complexity needed to achieve the validated outcome. Compare deterministic automation, an LLM workflow, a single agent, and multi-agent orchestration against a measurable business baseline.
Experiments also require an approved hypothesis, sandbox, permitted data, budget, and exit criteria before implementation.
Human presence is required here to confirm scope, intent, business meaning, and approval before the lifecycle can start.
ADLC Lifecycle
From requirements to operations, in a continuous cycle
Requirements Quality Gate
No implementation starts without a passed requirements quality gate. The gate approves the next increment, not every future requirement. A quality gate agent may support preparation; accountable humans approve scope, measurable outcomes, risks, and known uncertainties.
Human in the loop: mandatory approval of requirements quality and intent.
Implement
Turn approved requirements into concrete capabilities, services, prompts, workflows, integrations, and reusable components. This is the stage where intent becomes a real solution, structured in a way that can be reviewed, tested, governed, and evolved over time without losing architectural coherence.
Implement the autonomy contract with least-privilege access, runtime policy enforcement, budgets, and stop controls. Humans remain designers and implementers as well as reviewers.
Review
Review the solution for quality, consistency, security, maintainability, and alignment with manifesto principles before advancing toward validation.
Human in the loop: expert review, risk judgment, and decision to proceed.
Review delegated authority, trust boundaries, memory handling, evaluation quality, and recovery plans, including irreversible effects.
Test
Validation of agent-produced software requires competent human oversight. Accountable people approve acceptance criteria, review test adequacy, and assess evidence and residual risk to authorize release. Agents may generate and execute tests, but cannot approve their own work or unilaterally weaken its acceptance conditions. A second agent does not replace human accountability; review depth is proportionate to risk, not a requirement to execute every test manually.
Validate expected behavior, edge cases, failure modes, reliability, and operational readiness through structured test evidence and measurable acceptance criteria.
Testing also covers behavioral regression caused by changes to prompts, RAG content, shared skills, model configuration, tools, and orchestration rules.
Use representative, versioned datasets, repeated trials, isolated state, and risk-based thresholds. Verify actual outcomes and policy compliance; calibrate model-based graders against human judgment and disclose uncertainty and coverage gaps.
Deploy
Release in a controlled, observable, and repeatable way, with rollback options, release notes, ownership, and deployment evidence clearly defined.
Release evidence must identify code changes, prompt changes, RAG or documentation changes, tool changes, model configuration changes, and orchestration changes.
Human in the loop: release authorization and accountability for go-live.
Distinguish configuration rollback, state restoration, and compensation for external effects. Irreversible actions require preventive controls and explicit approval; a rollback cannot undo every action.
Operate
Operate the solution using monitoring, alerts, runbooks, support flows, and governance checkpoints that keep the system reliable in real conditions.
Operations must monitor not only technical health, but also behavioral drift, unexpected answers, outdated knowledge usage, retrieval failures, and regressions introduced by knowledge updates.
Human in the loop: incident handling, escalation, and governance oversight in production.
Bound retries and prevent duplicate side effects. Test degraded operation, escalation, stop controls, and revocation. Measure cost per successful task, latency, intervention, rework, escalation, and business value against a baseline. Evidence may justify reducing autonomy or retiring a system.
Improve
Improve continuously based on production feedback, incidents, analytics, user insight, and delivery learnings that reveal what should be refined next.
Use production evidence to reduce autonomy or retire systems when value or reliability is insufficient. Revoke credentials, endpoints, and scheduled work; retain or delete memory under approved policy.
Orchestrate
Coordinate agents, flows, policies, and reusable capabilities in a composable ecosystem that scales beyond isolated implementations.
Propagate identity, permission limits, budgets, approval state, and traceability across delegation. Govern shared state and memory without silently expanding authority.
ADLC Operating Model
What each phase must produce to be governable in practice
Entry Conditions
Validated requirements, explicit business intent, named ownership, and a passed quality gate before any build activity starts.
Evidence and Progression Criteria
Use this checklist to validate evidence, not to repeat lifecycle activities. Assign named human owners; review depth is risk-based and execution may be automated. Failed mandatory controls block promotion. Operation and orchestration use ongoing controls, not a one-time exit gate.
Implementation Baseline
Minimum controls for an enterprise ADLC adoption
Principles become operational only when they are implemented as repeatable controls, measurable checks, and reviewable evidence.
Entry and Ownership
A passed requirements quality gate, measurable acceptance criteria, and named business, technical, and risk owners.
Versioned Behavior Surface
Code, prompts, knowledge, RAG sources, shared skills, model configuration, tool descriptions, and orchestration rules are versioned as controlled inputs.
Automated Evidence Gates
Tests, evaluations, policy checks, and required approvals run in delivery pipelines and prevent promotion when mandatory controls fail.
Behavioral Evaluation
Versioned evaluation datasets cover expected behavior, edge cases, unsafe actions, retrieval quality, escalation, and regressions.
Controlled Release
Every release carries approved evidence, a complete change inventory, accountable authorization, and tested recovery plans for configuration, state, and external effects.
Production Feedback
Tracing, audit events, quality signals, drift, retrieval failures, incidents, and human feedback feed the governed improvement loop.
ADLC Conformance Checklist
A team can claim alignment only when the controls are demonstrable
- No implementation begins before the requirements quality gate is passed.
- Every behavior-changing input has an owner, version, approval state, and change history.
- Requirements are traceable to implementation, knowledge, expected behavior, test evidence, and release.
- Human approval and escalation are enforced at the checkpoints required by risk and impact.
- Release inputs are versioned and observable; recovery distinguishes rollback, state restoration, and compensation, with preventive controls for irreversible actions.
- Production evidence is reviewed and converted into governed improvement work.
- Autonomy limits are documented, enforced, tested, and revocable.
- Risk-based evaluations use versioned datasets, repeated trials, actual outcomes, and human-calibrated graders.
SDLC and ADLC
The same lifecycle discipline, applied to a wider behavior surface
| Characteristic | Traditional SDLC | ADLC |
|---|---|---|
| Primary execution | Human-led software delivery | Coordinated human-agent delivery with explicit human accountability |
| Behavior | Primarily deterministic and code-driven | Also non-deterministic, adaptive, and influenced by runtime context |
| Controlled change surface | Source code, configuration, infrastructure, and data | Also prompts, knowledge and RAG, skills, model configuration, tools, and orchestration |
| Validation | Code, integration, system, security, and acceptance tests | The same controls plus continuous behavioral, retrieval, and regression evaluation |
| Human role | Author, reviewer, approver, and operator | Designer, implementer, operator, reviewer, approver, escalation owner, and accountable decision-maker |
| Evidence | Build, test, approval, and release records | End-to-end traceability from requirement to behavior, evidence, release, and operations |
Lifecycle Principles
- Tool-agnostic lifecycle
- Continuous improvement
- Governed execution
Outcome
A framework that is simple to explain, readable even for people outside the technical detail, yet structured enough to guide delivery and governance.
ADLC in Practice
Delivery and learning, connected by governance
In practice, ADLC is not a one-way pipeline. Teams enter through a requirements quality gate, move through delivery, and then loop back through operations, improvement, and orchestration to refine the next iteration.
- Requirements enter only after a dedicated quality gate and human approval.
- Implementation, review, and test transform intent into a governed solution.
- Knowledge updates, RAG sources, prompts, and shared skills are treated as controlled changes and must feed the same evidence, review, test, and improvement loop as code and workflows.
- Deploy and operate create live evidence, not just release output.
- Improve and orchestrate feed the next cycle with learning, reuse, and coordination.
Shared Skills
Company-specific know-how that agents can reuse consistently
Adapted to the enterprise
Shared skills should be selected from consolidated frameworks where useful, but adapted to the company's architecture, policies, vocabulary, risk model, and delivery culture.
They turn reusable know-how into governed execution patterns that agents and teams can apply consistently.
Documentation Skill
Defines how human documentation and agent context are produced as connected but separate artifacts.
Human documentation lives in tools designed for people. Agent documentation is exposed through governed Agent Context Endpoints, such as MCP (Model Context Protocol) servers, llms.txt files, retrieval indexes, or versioned context packs.
Agent-context tools may include Context7, GitMCP, MCPDoc, mcp-documentation-server, custom MCP servers built with open MCP SDKs, or equivalent open-source systems. These endpoints must expose stable URLs, source ownership, versioning, approval status, and retrieval rules.
Retrieve only the approved context needed for the task. Reduce token usage without removing permissions, constraints, provenance, or evidence needed for a correct decision.
Publish context reusable across projects and teams, avoiding divergent manual copies and preserving links to authoritative sources.
Knowledge Governance Skill
Defines how knowledge sources and agent context are selected, owned, approved, structured, versioned, published, tested, traced, and retired.
It covers RAG sources, context endpoints, shared knowledge, contradiction handling, freshness, retrieval evaluation, citation expectations, access rules, and behavioral regression testing after knowledge changes.
Runtime context and memory require provenance, permitted writers, retention, user and tenant isolation, deletion, and contradiction handling. Retrieved content cannot grant authority. Compression must preserve permissions, constraints, and decision-critical evidence.
Release Notes Skill
Defines how release notes are generated, grouped, reviewed, and translated for technical, business, and operational audiences.
It can include rules for breaking changes, migrations, known issues, rollback notes, and customer-facing summaries.
Architecture Skill
Captures the enterprise's architectural principles, decision criteria, reference patterns, and review expectations.
It helps agents reason with local standards instead of generic architecture advice.
Infrastructure Skill
Encodes platform conventions for environments, deployment, observability, rollback, naming, ownership, and operational readiness.
It should reflect the real infrastructure model used by the company, not an abstract cloud checklist.
CISO Security Skill
Security skills should be defined or validated by the CISO organization and aligned with enterprise policies.
Examples include data handling, identity, secrets, access control, threat modeling, secure prompt/tool usage, and audit evidence.
Behavioral Evaluation Skill
Defines representative datasets, repeated trials, risk-based acceptance thresholds, outcome and policy checks, human-calibrated graders, and regression evidence after behavior changes. Links quality, cost, latency, and human intervention to release decisions.
Shared Agents
Reusable capabilities that support the full ADLC
Documentation Agent
Creates and updates human-facing documentation in the official human knowledge base, such as Confluence, SharePoint, Notion, GitBook, Backstage TechDocs, Read the Docs, or similar platforms.
Human documentation is optimized for reading, review, onboarding, governance, and auditability. It is not the default context interface for AI (Artificial Intelligence) agents.
Owns ADRs, runbooks, onboarding pages, architecture notes, FAQs, and process documentation tied to real delivery events.
PR Governance Agent
Supports pull requests end-to-end by summarizing changes, checking policy, highlighting risk, and proposing reviewers.
Helps keep reviews consistent, traceable, and aligned with shared engineering guardrails.
Release Notes Agent
Generates release notes from merged work, grouping features, fixes, breaking changes, migrations, and operational notes.
Produces both technical and business-friendly summaries for internal and external communication.
Knowledge Sync Agent
Detects gaps between code, tickets, releases, and documentation, then proposes or performs the missing updates.
Keeps the delivery reality and the knowledge base aligned over time.
Knowledge Governance Agent
Reviews and governs knowledge and agent-context sources before they are used by agents. It checks freshness, ownership, approval and version status, duplication, contradictions, business validity, traceability, retrieval quality, and regression impact.
It helps ensure that documents, context endpoints, RAG content, and shared knowledge improve agent behavior without introducing uncontrolled change.
Compliance and Traceability Agent
Links requirements, implementations, tests, documentation, and releases into an auditable chain of evidence.
Supports quality gates, reviews, and governance checkpoints across the lifecycle.
Operational Readiness Agent
Checks that each release is backed by runbooks, ownership, rollback guidance, alerts, and operational readiness evidence.
Helps teams move from deployment to stable operation with fewer blind spots.
Tooling capabilities
Tooling capabilities for a governed ADLC
This ADLC map groups tooling capabilities that support its controls, drawing on established and emerging standards and technical practices. It is not a normative taxonomy or a mandatory stack: one tool may cover several capabilities, and existing enterprise services can be reused. Select implementations according to the approved scope, risk, and architecture.
Retrieval is needed only when the system retrieves external knowledge; persistent workflows are appropriate when execution must survive interruptions or coordinate long-running actions. A multi-provider gateway is optional when centralized model access or routing is needed. These components do not replace the requirements quality gate or accountable human oversight.
References support the underlying capabilities, not this exact classification or ADLC conformance. Standards and frameworks describe processes or controls; research studies specific methods; technical documentation illustrates implementations.
| Capability | What to use | Control to demonstrate |
|---|---|---|
| Requirements and traceability Standard: ISO/IEC/IEEE 29148 | A requirements register linked to decisions, tests, and releases. | Approved scope, measurable acceptance criteria, ownership, and a passed quality gate. |
| Versioning and delivery Framework: NIST SSDF | Version control, artifact storage, and automated delivery pipelines. | Reviewable changes to code, prompts, skills, and configuration; promotion blocked when mandatory checks fail. |
| Knowledge, context, and documentation Technical documentation: Context engineering | Human-facing documentation plus a separate agent-context interface, source catalog, retrieval index, and memory policies where needed. | Source ownership, approval, provenance, freshness, access control, retention, and deletion; context must preserve constraints. |
| Identity and delegated access Standard: RFC 8693 | An identity provider, service identities, authorization controls, and a secrets manager. | Who acts, on whose behalf, and within which permissions; least privilege, scoped delegation, expiry, and revocation. |
| Runtime policy and consumption limits Technical documentation: Policy enforcement Technical documentation: Gateway budgets | Policy enforcement at tool boundaries, usage counters, quotas, and stop controls. | Limits on actions, spend, duration, calls, and retries; denied actions are blocked, not merely logged. |
| Orchestration and recovery Technical documentation: Durable execution | Execution controls and recovery procedures; a persistent workflow runtime where resumability or long-running coordination is required. | Resumable execution, idempotency, stop conditions, state reconciliation, and authorized compensation. |
| Human review Framework: NIST AI 600-1 | A review queue with evidence, authorized reviewer assignment, expiry, and escalation. | Trained reviewers can challenge or stop actions; approval is tied to the exact action, with decision evidence and no silent approval on timeout. |
| Behavioral evaluation Technical documentation: Agent evaluations | Versioned test datasets, evaluation runners, adversarial tests, and human calibration. | Repeated trials, actual outcomes, policy compliance, risk-based thresholds, and regression gates. |
| Observability, costs, and outcomes Technical documentation: OpenTelemetry GenAI | Traces, metrics, alerts, cost accounting, and operational dashboards. | Behavioral drift, retrieval failures, cost per successful task, latency, intervention, and business outcomes. Telemetry alone does not demonstrate business value; assess outcomes against an approved baseline. |
| Audit and incident management Technical documentation: Decision logs Framework: NIST SP 800-61r3 | Protected evidence storage, incident workflows, and operational runbooks. | Reconstruct decisions and changes, handle incidents, test recovery, and retire access and data under policy. |
| LLM gateway and model routing Research: RouteLLM Technical documentation: LLM gateway | Where needed, a multi-provider gateway with evaluated routing, input/output token policies, caching, and consumption controls. | Approved model selection, separate input/output usage evidence, bounded spend, and quality-preserving optimization. |
Enterprise selection criteria
Verify SSO (Single Sign-On) and roles, tenant isolation, retention and deletion, exportable audit evidence, hosting and data residency, operational support, and integration with existing controls. Open-source licensing alone does not establish suitability.
Enterprise Tooling Examples
Products that can implement parts of the ADLC control model
These examples are non-normative. Using a product does not by itself make a team ADLC-aligned: controls, evidence, ownership, and accountable decisions remain mandatory.
| Capability | Tool | Enterprise Use | Open Source Status | URL |
|---|---|---|---|---|
| Requirements and approvals | Jira | Structured requirements, workflows, approvals, ownership, and traceability records. | No - commercial | https://www.atlassian.com/software/jira |
| Delivery and evidence gates | GitLab | Version control, review, CI/CD, policy gates, security checks, and release evidence. | Open core - CE is MIT; enterprise features are proprietary | https://about.gitlab.com/ |
| Behavioral testing | promptfoo | Prompt, RAG, agent, and red-team evaluations that can run locally or in CI pipelines. | Yes - MIT project; commercial enterprise offering | https://www.promptfoo.dev/ |
| Tracing and evaluation | Langfuse | Tracing, prompt management, evaluation datasets, experiments, and production feedback. | Open core - core is MIT; enterprise add-ons are commercial | https://langfuse.com/ |
| Policy decisions | Open Policy Agent | Policy-as-code for delivery gates and runtime authorization. The integrated service or gateway must enforce the decisions; decision logs support traceability. | Yes - Apache-2.0 | https://www.openpolicyagent.org/ |
| Human documentation | Backstage TechDocs | Human-facing software catalog and docs-as-code integrated with engineering ownership. | Yes - Apache-2.0 | https://backstage.io/docs/features/techdocs/ |
| Technical context for coding agents | Context7 | Version-aware library documentation and code examples through MCP and CLI. An example of technical context delivery, not a complete governance platform for all enterprise knowledge. | Partial - MCP server is MIT; hosted backend is private | https://context7.com/ |
| Durable workflow execution | Temporal | Persistent workflows, failure recovery, and coordination of waits and approvals. Idempotency and compensation for external effects must still be designed. | Yes - MIT server; commercial cloud service | https://github.com/temporalio/temporal |
| Secrets and temporary credentials | OpenBao | Centralized secrets, dynamic credentials for supported systems, expiry, and revocation. Supports least-privilege access without placing credentials in prompts. | Yes - MPL-2.0 | https://github.com/openbao/openbao |
| Source ownership and provenance | OpenMetadata | Metadata catalog, ownership, quality signals, lineage, and impact analysis for governed data context. Complements, rather than replaces, knowledge approval and behavioral testing. | Yes - Apache-2.0 project | https://github.com/open-metadata/OpenMetadata |
Alternatives and optional components
Arize Phoenix: Arize Phoenix is an alternative for tracing, retrieval evaluation, experiments, and behavioral diagnostics. It is source-available under ELv2, not OSI-approved open source. License.
LangGraph: LangGraph is an optional MIT-licensed framework for stateful agents, checkpoints, and suspension/resumption for human review. It is not a complete governance platform; the human review interface, reviewer competence, authorization, and approval policies must still be implemented.
These are capability examples, not a mandatory stack or a guarantee of ADLC conformity. Select only the components needed for the approved scope and verify edition-specific licensing and operational requirements.
LLM Gateway
LLM Gateways: multi-provider routing and token control
An LLM gateway should govern access to multiple providers and route each task to the most suitable approved model, balancing evaluated quality, risk, latency, availability, and cost. Load balancing or choosing the cheapest model alone does not establish task suitability.
- Inbound tokens: Select relevant context, remove duplication, and use caching or evaluated compression without losing instructions, permissions, citations, or evidence. Isolate caches by tenant and authorization; include source and model versions in cache policies.
- Outbound tokens: Set provider-supported generation limits, response formats, and verbosity policies before inference. Bound retries and agent loops. Shortening an already generated answer does not reduce the tokens already billed.
- Evidence and budgets: Measure input, output, cached, and reasoning tokens where reported, together with cost per successful task. Enforce team and workload budgets; regression-test routing, compression, and fallback changes. A fallback must preserve data residency, permission, and quality constraints.
| Gateway / official sources | License / offering | Multi-provider routing | Token and consumption controls |
|---|---|---|---|
| LiteLLM Documentation | Open-source core: MIT; enterprise modules separately licensed. | Cost/latency strategies and fallbacks across providers. | Caching and usage limits; configure output-token parameters and any context reduction. |
| Portkey AI Gateway Documentation | Open-source gateway: MIT; hosted/enterprise offerings are separate. | Multi-provider routing, load balancing, and fallbacks. | Caching; advanced optimization depends on edition. Validate output limits and context policies. |
| Kong AI Gateway Documentation | Commercial advanced AI capabilities; verify edition and plugin entitlement. | Multi-provider and semantic routing through configured plugins. | Semantic cache, token/cost limits; prompt compression requires a service. Configure output limits separately. |
| Cloudflare AI Gateway Documentation | Proprietary managed service; verify current plan limits. | Conditional routes, model choices, fallbacks, and budgets. | Caching and cost quotas; generation limits depend on provider parameters. Context reduction needs integration. |
Open-source gateways are listed first, followed by commercial services. Examples are not endorsements or a required stack. No row implies automatic support for every input/output policy: verify the deployed version, provider compatibility, and edition, including streaming and budget enforcement under concurrent requests.
Useful Links
External resources for agentic delivery and governance
Governance and standards
Durable references for enterprise risk, accountability, security, and lifecycle governance.
| Resource | Description | Link |
|---|---|---|
| NIST AI Risk Management Framework | Vendor-neutral framework for managing AI risks and trustworthiness across design, development, deployment, use, and evaluation. | nist.gov/ai-rmf |
| NIST Generative AI Profile | Companion profile that applies the AI RMF to generative AI risks and lifecycle controls. | nist.gov/genai-profile |
| ISO/IEC 42001 | International standard for AI management systems, covering policy, accountability, risk controls, and continual improvement. The full standard is commercial. | iso.org/standard/42001 |
| MITRE ATLAS | Living knowledge base of adversary tactics and techniques for AI systems, including agentic threats and mitigations. | atlas.mitre.org |
| OWASP Agentic AI Threats and Mitigations | Threat-model-based taxonomy and mitigation guidance for autonomous and agentic AI systems. | genai.owasp.org |
| OWASP State of Agentic AI Security and Governance | Landscape report on current agentic security and governance practices. Useful as scenario reading rather than a normative standard. | genai.owasp.org/state-of-agentic-ai |
Protocols and observability
Open specifications for context integration, agent interoperability, and portable operational evidence.
| Resource | Description | Link |
|---|---|---|
| Model Context Protocol | Open protocol for connecting agentic applications to governed tools, data sources, and context services. | modelcontextprotocol.io |
| Agent2Agent Protocol | Apache-2.0 open standard for discovery, secure interaction, and collaboration between independent agentic systems. | a2a-protocol.org |
| OpenTelemetry GenAI Semantic Conventions | Apache-2.0 conventions for portable traces, metrics, events, retrieval, tool calls, MCP, and agent execution evidence. | github.com/open-telemetry/semantic-conventions-genai |
Practices and optimization
Implementation resources that teams should assess against their own controls, platforms, and risk model.
| Resource | Description | Link |
|---|---|---|
| Microsoft APM | MIT-licensed dependency manager for portable, versioned, policy-governed agent instructions, skills, plugins, and MCP servers. | github.com/microsoft/apm |
| Superpowers | Open-source skills framework and delivery methodology for design, planning, TDD, review, and agent-assisted development. | github.com/obra/superpowers |
| GitHub Copilot Token Optimization | Community, product-specific guidance for reducing context and token consumption while preserving delivery quality. | github.com/olivomarco/github-copilot-token-optimization |
Glossary and acronyms
| Term | Expanded name / concept | Meaning in ADLC |
|---|---|---|
| ADLC | Agentic Development Lifecycle | Lifecycle for agentic systems, extending SDLC with governance of behavior, context, and autonomy. |
| SDLC | Software Development Lifecycle | Software lifecycle discipline, from requirements through delivery, operation, and retirement. |
| AI | Artificial Intelligence | Artificial intelligence capabilities used within the system, subject to the same governance controls. |
| LLM | Large Language Model | Language model used by agents; its version and configuration affect behavior and require validation. |
| RAG | Retrieval-Augmented Generation | Retrieval of external information to support generation; optional, with governed sources and retrieval tests. |
| MCP | Model Context Protocol | Protocol for connecting AI applications to tools and context; it does not replace authorization or governance. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | Continuous integration and delivery or deployment, with required checks before promotion. |
| IAM | Identity and Access Management | Management of identities and permissions, including service identities and limited delegation. |
| SSO | Single Sign-On | Single authentication across services; it does not by itself grant permission to perform actions. |
| Human in the Loop | HITL | Trained, accountable human review at critical checkpoints, with evidence and authority to intervene. |
| Quality gate | Quality gate | Evidence-based entry or promotion check; a passed requirements gate is mandatory before implementation. |
| Agent context | Agent context | Information available to an agent for a task, including instructions, retrieved sources, tools, and memory. |
| Guardrail | Guardrail | Preventive or detective control limiting unsafe or unauthorized behavior; critical limits require runtime enforcement. |
| Orchestration | Orchestration | Coordination of agents, tools, state, and workflows within approved permissions and budgets. |
| Context engineering | Context engineering | Selection and composition of operational context; it complements, not replaces, knowledge governance. |