Agent Context For The Agentic SDLC Adoption Guide

Current through: July 6, 2026

Use this file as the primary context entry point when an agent helps a software team apply the Agentic SDLC Adoption Guide. Humans use the interactive workbench to enter project context and export state. Agents use this Markdown packet to understand the operating model before helping with the work.

Core Premise

Software engineering teams are being asked to adopt agents into real delivery work. Agents can help design, build, test, refactor, document, and operate software. That part is no longer the hard question. The harder question is whether engineers, architects, and technical leaders can keep agent-assisted work aligned with the domain, architecture direction, constraints, security posture, and business outcome.

The operating problem is drift. Agent-assisted work may move quickly while missing the domain, violating the architecture, weakening security, or changing behavior without understanding why that behavior existed. Teams need artifacts, tests, and review gates that keep agent work aligned with the intended design.

Traditional SDLC artifacts solve part of that problem. Requirements, design specs, architecture decision records, acceptance criteria, test plans, data models, interface contracts, and runbooks become operating instructions for agents and review material for humans.

Core shape:

1. Humans define the problem, architecture, constraints, standards, and acceptance path.
2. Engineering artifacts turn that intent into instructions both humans and agents can use.
3. Agents execute bounded work inside the frame set by those artifacts.
4. Humans review, verify, and decide whether the work is correct, secure, maintainable, and aligned with the business problem.
5. Teams use agents to help keep artifacts, tests, and review gates current as the work changes, while humans stay responsible for direction, judgment, and acceptance.

Teams may use the full adoption path or only the section that matches the current work. The same core shape applies even when the team uses one section at a time.

Source Priority

Use sources in this order:

1. This file.
2. agent-guide.md.
3. The relevant section file under sections/.
4. agent-prompts.md.
5. The user's exported project-state JSON.
6. Local project files the user explicitly provides.

If sources conflict, prefer the user's current project evidence over generic guide language. If local policy or regulation conflicts with this guide, local policy wins.

Agent Contract

When helping a team use this material:

• Separate facts, assumptions, recommendations, and open questions.
• Ask for missing inputs only when the output would otherwise be unsafe or misleading.
• Produce bounded artifacts the reader can review, such as an intake brief, discovery plan, architecture option comparison, test plan, security review checklist, readiness review, or roadmap.
• Help maintain supporting artifacts, tests, review gates, and handoff material when asked, but keep human review and acceptance explicit.
• Support selective use. If the reader brings only one section, help with that section without requiring the full workbench first.
• Identify required local reviewers for security, privacy, legal, compliance, clinical, financial, safety, regulated data, and domain architecture concerns.
• Do not approve production release, compliance, security acceptance, legal position, medical decision, financial decision, or safety-critical operation.
• Do not ask the user to paste secrets, credentials, private customer data, regulated data, or proprietary details into an external agent.

Guide Sections

• Start Here: operating mode, decision owners, artifact set, and human review boundary.
• Operating Principles: practical architecture doctrine, first-principles hierarchy, and anti-over-engineering checks.
• Project Intake And Classification: product, users, owners, constraints, project type, risk class, and outcomes.
• First-Principles Product Canvas: product thesis, users, workflows, MVP scope, non-goals, and acceptance shape.
• Prototype And Current-State Discovery: current SDLC, prototype disposition, evidence classes, data sensitivity, and productionization gaps.
• Workflow And Process Mapping: actors, triggers, states, exceptions, business rules, and acceptance criteria.
• Domain And Data Model: entities, lifecycle, audit, retention, migrations, and test data.
• Architecture Options And Decision Matrix: architecture options, quality attributes, weighted scoring, tradeoffs, and revisit trigger.
• Target Architecture Package: diagram set, technical design, ADRs, module map, and implementation slice map.
• Agentic Engineering SDLC: agent operating loop, human gates, traceability, and documentation reconciliation.
• Testing And Validation Strategy: layered tests, golden scenarios, UAT scripts, and failure interpretation.
• Environments, Release Path, And Operations: local, preview, UAT, production, promotion path, rollback, and runbook.
• Security And Secure-By-Design: auth, authorization, secrets, audit, dependency checks, and agent-specific security.
• Client Visibility And Governance: decision log, UAT package, known limitations, release notes, and safe visibility boundaries.
• Production Readiness: product, data, security, quality, operations, and business readiness domains.
• 30/60/90 Roadmap Builder: staged delivery, milestone evidence, owner decisions, and expansion path.
• Templates And Worksheets: decision object, implementation slice object, business rule object, and risk register.
• Prompt Library: copy-ready agent work orders for discovery, diagrams, product shape, design, execution planning, testing, security, review, readiness, and client summary.
• Study Guide And Research Foundation: study path and source library usage.
• Source Library: source references embedded in the workbench for periodic review and monthly heartbeat work.

Project-State JSON

The workbench exports a project-state packet that follows project-state.schema.json. Treat exported JSON as potentially sensitive. Before using it, summarize what it contains and ask the reader to remove material they should not share.

Key fields:

• schemaVersion
• guideVersion
• generatedAt
• sourceLibraryVersion
• projectProfile
• completedSections
• progress
• worksheetValues
• checklistState
• architectureScores
• architectureRecommendation
• readinessScores
• riskRegister
• roadmap
• promptLibrary
• requiredLocalReviewers
• unresolvedRisks
• rawState

Output Rules

Every useful output should include:

• Purpose.
• Inputs used.
• What is known.
• What is assumed.
• Recommended next actions.
• Required local reviewers.
• Risks and unresolved questions.
• Evidence needed before relying on the recommendation.

For high-stakes systems, end with a clear local-review gate before the reader acts.

Limits

llms.txt and this Markdown packet help agents find context. They do not force any model, crawler, or tool to use the guide correctly.

This material is a planning and review aid. It does not make a project safe, compliant, secure, production-ready, or fit for a regulated domain by itself.