# AI Agent Implementation Roadmap Template

Use this roadmap for one bounded agent workflow from intake through production operation and retirement. Adapt the phases, timing, and evidence to the workflow's risk, complexity, and obligations.

This template is educational material, not legal, security, privacy, compliance, financial, workforce, or risk advice. Do not put passwords, tokens, private keys, recovery codes, customer records, sensitive or unnecessary personal data, or model private reasoning in this document. Use approved work identities for accountable owners and protected references for sensitive evidence.

## Roadmap Record

- Roadmap ID: [Stable ID]
- Organization ID: [Stable ID]
- Source tenant, workspace, and account IDs: [Every applicable boundary]
- Target tenant, workspace, and account IDs: [Every applicable boundary, or Same as source]
- Agent ID: [Stable ID or To be assigned]
- Workflow ID: [Stable ID]
- Business owner: [Approved work identity]
- Technical owner: [Approved work identity]
- Roadmap owner: [Person responsible for completeness, versioning, and gate scheduling]
- Version: [Version or digest]
- Status: [Draft | Approved | Active | Paused | Complete | Retired]
- Planned start: [Date]
- Current phase: [Phase]
- Next gate date: [Date]
- Handling classification: [Classification]
- Authorized readers and editors: [People or roles]
- Evidence repository: [Protected reference]
- Retention period: [Policy or date]

This roadmap records intended work and gate decisions. It does not grant technical access, approve a pilot or production release, or authorize runtime actions. Current identity, authorization, approval, gateway, tool, and target-system controls must authorize every operation at execution time.

## 1. Outcome, Scope, and Roadmap Decision

- Workflow problem: [Measured problem]
- Intended business or user outcome: [Outcome]
- Primary measure and baseline: [Definition, value, source, population, and window]
- Minimum useful result: [Threshold]
- Guardrail outcomes: [Measures that must not worsen]
- Approved users or initiating principals: [Stable IDs]
- Affected people or groups: [Description]
- Technical environments: [Development | Test | Staging | Production | Other]
- Allowed data classes: [Classes]
- Expected external effects: [None or exact effects]
- Maximum planned authority: [Read, draft, write, send, execute, spend, schedule, delegate]
- Prohibited actions and outcomes: [List]
- Out-of-scope workflows: [List]
- Decision requested now: [Discovery | Design | Prototype | Pilot preparation | Other]
- Decision owner: [Authenticated principal]
- Funding, time, and exposure limit: [Limit]

Alternatives considered:

| Option                   | Expected outcome | Cost range | Risk   | Evidence    | Reason to continue or reject |
| ------------------------ | ---------------- | ---------- | ------ | ----------- | ---------------------------- |
| Business as usual        | [Outcome]        | [Range]    | [Risk] | [Reference] | [Reason]                     |
| Process or policy change | [Outcome]        | [Range]    | [Risk] | [Reference] | [Reason]                     |
| Deterministic automation | [Outcome]        | [Range]    | [Risk] | [Reference] | [Reason]                     |
| Assisted workflow        | [Outcome]        | [Range]    | [Risk] | [Reference] | [Reason]                     |
| Bounded AI agent         | [Outcome]        | [Range]    | [Risk] | [Reference] | [Reason]                     |

## 2. Phase and Gate Map

Do not assign a calendar date until the entry evidence, work, dependencies, and decision owner are known. A target date never clears a gate.

| Phase                                   | Entry criteria | Main work | Required artifacts | Exit evidence | Decision owner | Target date | Status   |
| --------------------------------------- | -------------- | --------- | ------------------ | ------------- | -------------- | ----------- | -------- |
| 1. Ownership and intake                 | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 2. Workflow selection and baseline      | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 3. Scope, risk, and charter             | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 4. Data, context, identity, and systems | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 5. Build and pre-pilot evaluation       | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 6. Controlled pilot                     | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 7. Production release                   | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |
| 8. Operate, improve, scale, and retire  | [Criteria]     | [Work]    | [Artifacts]        | [Evidence]    | [Owner]        | [Date]      | [Status] |

Allowed gate decisions: [Stop | Return for changes | Proceed within exact scope | Proceed with verified conditions]

Every gate record must bind the authenticated decision maker, authority source and effective role, roadmap version, exact workflow and release scope, source and target tenant boundaries, evidence cutoff, decision time, expiry, conditions, and protected evidence reference.

## 3. Owners, Workstreams, and Dependencies

| Workstream                         | Accountable owner | Contributors | Deliverable   | Dependency   | Escalation path |
| ---------------------------------- | ----------------- | ------------ | ------------- | ------------ | --------------- |
| Business outcome and process       | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Product and user experience        | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Governance, legal, and risk        | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Security and identity              | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Data and privacy                   | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Context and Skills                 | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Agent engineering and integrations | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Evaluation and independent review  | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Change, training, and support      | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |
| Operations and incident response   | [Owner]           | [People]     | [Deliverable] | [Dependency] | [Path]          |

- Separation-of-duties requirements: [Rules]
- Required independent reviewers: [People or roles]
- Vendor or third-party dependencies: [References]
- Procurement, contract, residency, retention, deletion, exit, and incident requirements: [References]
- Staffing and on-call assumptions: [Assumptions]
- Blocked dependencies and owners: [List]

## 4. Workflow, Requirements, and Architecture

Workflow boundary:

- Trigger: [User, event, schedule, or parent agent]
- Inputs and authoritative sources: [References]
- Outputs and destinations: [References]
- Normal path: [Steps]
- Exceptions and human handoffs: [Steps]
- Completion proof: [Authoritative outcome]
- Reconciliation method: [Method]
- Volume, peak load, latency, duration, and cost limits: [Limits]
- Accessibility, notice, appeal, correction, and user-support requirements: [Requirements]

Authority matrix:

| Operation                                        | Target system and object | Source and target tenant scope | Material parameters | Required approval | Enforcement point | Evidence source | Failure behavior           |
| ------------------------------------------------ | ------------------------ | ------------------------------ | ------------------- | ----------------- | ----------------- | --------------- | -------------------------- |
| [Read, draft, write, send, execute, or delegate] | [Target]                 | [Boundaries]                   | [Limits]            | [Rule]            | [Control]         | [Reference]     | [Fail closed and fallback] |

Architecture record:

| Component                      | Stable ID | Version or service | Owner   | Trust boundary | Failure mode | Replacement or exit path |
| ------------------------------ | --------- | ------------------ | ------- | -------------- | ------------ | ------------------------ |
| Model deployment               | [ID]      | [Version]          | [Owner] | [Boundary]     | [Failure]    | [Path]                   |
| Agent runtime and sandbox      | [ID]      | [Version]          | [Owner] | [Boundary]     | [Failure]    | [Path]                   |
| Tool or integration            | [ID]      | [Version]          | [Owner] | [Boundary]     | [Failure]    | [Path]                   |
| Approval service               | [ID]      | [Version]          | [Owner] | [Boundary]     | [Failure]    | [Path]                   |
| Monitoring and evidence system | [ID]      | [Version]          | [Owner] | [Boundary]     | [Failure]    | [Path]                   |

## 5. Data, Context, Identity, and Access

Data record:

| Data source or output | Class   | Purpose   | Allowed fields | Prohibited fields | Retention and deletion | Owner   | Evidence    |
| --------------------- | ------- | --------- | -------------- | ----------------- | ---------------------- | ------- | ----------- |
| [Source]              | [Class] | [Purpose] | [Fields]       | [Fields]          | [Rule]                 | [Owner] | [Reference] |

Managed context record:

| Resource                  | Stable ID | Authority and authorized scope       | Permission source | Route source and mode          | Evaluated version or baseline | Change response                    |
| ------------------------- | --------- | ------------------------------------ | ----------------- | ------------------------------ | ----------------------------- | ---------------------------------- |
| Knowledge or instructions | [ID]      | [Informational or must-follow scope] | [Reference]       | [Direct or Group Always route] | [Published version]           | [Continue, retest, or stop]        |
| Skill package             | [ID]      | [Authorized scope]                   | [Reference]       | [Direct or Group Always route] | [Published digest]            | [Continue, retest, or stop]        |
| Working Memory            | [ID]      | [Authorized scope]                   | [Reference]       | [Direct or Group Always route] | [Version or baseline]         | [Continue, reset, retest, or stop] |

Other behavior-shaping inputs:

| Input                                      | Source       | Version, digest, or capture rule | Authority                   | Validation and change response |
| ------------------------------------------ | ------------ | -------------------------------- | --------------------------- | ------------------------------ |
| System and harness prompts                 | [Reference]  | [Version]                        | [Harness authority]         | [Rule]                         |
| Request and conversation state             | [Reference]  | [Capture rule]                   | [Request authority]         | [Rule]                         |
| Artifacts                                  | [References] | [Exact Artifact version IDs]     | [No instruction authority]  | [Rule]                         |
| Messages                                   | [References] | [Message IDs or capture rule]    | [No instruction authority]  | [Rule]                         |
| MCP descriptors and approved configuration | [References] | [Versions]                       | [Capability only]           | [Rule]                         |
| Runtime inputs and tool results            | [Sources]    | [Capture rule]                   | [No self-granted authority] | [Rule]                         |

Permissions govern repository access, while routes govern delivery independently. Always routes resolve the current published Knowledge or Skill and current Memory, so an evaluated version in this roadmap does not pin delivery. AGENTS.md is the familiar combination of must-follow Knowledge and Always routing, not a separate Resource type. Artifacts and messages have no instruction authority. MCP tool results are Runtime context.

Identity and access:

- Agent identity and credential broker: [References]
- Initiating principal capture: [Method]
- Authentication method: [Method]
- Per-operation authorization policy: [Reference]
- Source and target tenant binding: [Method]
- Least-privilege grants and expiry: [References]
- Approval identity, authority, binding, expiry, and replay protection: [Rules]
- Revocation method and tested deadline: [Method]
- Delegation depth, audience, scope, expiry, and redelegation rule: [Rules]

Authentication material and secrets remain outside managed context and this roadmap. Untrusted content cannot grant itself authority or become governed Knowledge, a Skill, or working Memory without an authorized decision.

## 6. Evaluation, Prototype, and Pilot Plan

- Frozen evaluation set ID and version: [Reference]
- Live sample method: [Method]
- Representative conditions: [Conditions]
- Adverse, denied, edge, and dependency-failure cases: [Cases]
- Baseline and comparison method: [Method]
- Failed, aborted, retried, and excluded-run denominator rules: [Rules]
- Independent outcome source: [Reference]
- Human review method and workload limit: [Method]
- Pilot scope, users, authority, data, volume, dates, and spend: [Limits]
- Early-stop criteria: [Criteria]
- Pilot stop and recovery test: [Reference]

| Gate measure               | Numerator and denominator | Source and window | Required threshold | Stop threshold   | Owner   |
| -------------------------- | ------------------------- | ----------------- | ------------------ | ---------------- | ------- |
| Primary workflow outcome   | [Definition]              | [Reference]       | [Pass]             | [Stop]           | [Owner] |
| Quality or error           | [Definition]              | [Reference]       | [Pass]             | [Stop]           | [Owner] |
| Authorization and approval | [Definition]              | [Reference]       | [Pass]             | [Zero tolerance] | [Owner] |
| Data and tenant isolation  | [Definition]              | [Reference]       | [Pass]             | [Zero tolerance] | [Owner] |
| Human review load          | [Definition]              | [Reference]       | [Pass]             | [Stop]           | [Owner] |
| Reliability and recovery   | [Definition]              | [Reference]       | [Pass]             | [Stop]           | [Owner] |
| Unit and total cost        | [Definition]              | [Reference]       | [Pass]             | [Stop]           | [Owner] |

Passing an average outcome cannot offset a prohibited event or failed required control. A successful pilot makes the workflow a production candidate; it does not approve production.

## 7. Production Release and Operating Readiness

Exact production candidate:

- Release ID and digest: [Reference]
- Code, model, runtime, configuration, tools, schemas, data, context, and control versions: [References]
- Approved production scope: [Users, environment, authority, data, volume, schedule, and spend]
- Material differences from pilot: [Differences and tests]
- Open defects, risks, exceptions, and conditions: [References]
- Deployment checklist: [Reference]
- Rollout stages and exposure caps: [Stages]
- Rollback criteria and method: [Reference]
- Support and on-call readiness: [Evidence]
- User training and communications: [Evidence]

Monitoring and evidence:

- Outcome, control, reliability, cost, and workload measures: [References]
- Alert thresholds, owners, and response targets: [Rules]
- Authenticated, tenant-bound, append-only or tamper-evident evidence location outside the evaluated agent's write and delete authority: [Reference]
- Evidence retention and access rules: [Rules]
- Incident, suspension, recovery, and notification plans: [References]
- Review cadence and event-driven review triggers: [Rules]

For context evidence, distinguish compilation, response issuance, integration acknowledgment, host-confirmed session injection, and agent consumption. One stage does not prove the next. Record consumption only from direct, authenticated attestation by a trusted integration or provider; otherwise record it as unknown.

## 8. Stop, Recovery, Change, and Retirement

Stop boundaries:

| Boundary                                  | Stop method                                 | Owner   | Confirmation source          | Deadline | Missing-confirmation escalation | Last test  |
| ----------------------------------------- | ------------------------------------------- | ------- | ---------------------------- | -------- | ------------------------------- | ---------- |
| New and in-flight runs                    | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |
| Credentials and target-side sessions      | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |
| Queues, schedules, callbacks, and retries | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |
| Pending approvals and held actions        | [Invalidate or require fresh authorization] | [Owner] | [Target-system confirmation] | [Time]   | [Action]                        | [Evidence] |
| Child agents and delegated grants         | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |
| Tools, integrations, and context routes   | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |
| Persistent state and caches               | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |
| Downstream and external work              | [Method]                                    | [Owner] | [Reference]                  | [Time]   | [Action]                        | [Evidence] |

Keep the workflow suspended until every required boundary confirms containment. Escalation triggers more containment work and cannot replace confirmation. Recovery requires reconciliation, a known-good release and context baseline, required retesting, and approval from the named recovery authority.

Material-change triggers: [Purpose, users, affected people, authority, data, context, tools, model, runtime, persistence, delegation, controls, evaluation method, or external effects]

| Change   | Affected phase and evidence | Retests | Approver | Rollout and rollback | Status   |
| -------- | --------------------------- | ------- | -------- | -------------------- | -------- |
| [Change] | [Impact]                    | [Tests] | [Owner]  | [Plan]               | [Status] |

Retirement plan:

- Retirement trigger and decision owner: [Rule]
- Replacement or manual fallback: [Reference]
- Identity, credential, grant, route, integration, schedule, queue, and callback removal: [References]
- Data, Memory, Artifact, log, and evidence retention or deletion: [Rules]
- Pending and external action reconciliation: [Evidence]
- User and affected-party notice: [Evidence]
- Final activity verification: [Evidence]
- Inventory and ownership update: [Evidence]

## 9. Gate Decision Record

Create one record for every phase gate. A target date, completed task, demo, or roadmap status cannot replace an authorized decision.

- Gate ID: [Stable ID]
- Phase: [Phase]
- Decision: [Stop | Return for changes | Proceed within exact scope | Proceed with verified conditions]
- Authenticated decision maker: [Stable principal ID]
- Authority source and effective role at decision time: [Protected reference]
- Roadmap version or digest: [Version]
- Exact workflow, release, environment, authority, data, context, tools, volume, schedule, and spend approved: [References]
- Source and target tenant, workspace, and account IDs: [Boundaries]
- Evidence cutoff: [Timestamp]
- Decision time: [Timestamp]
- Expiry: [Timestamp]
- Conditions, owners, due dates, and closure verifiers: [References]
- Decision evidence: [Protected reference]

Any rejection, missing or expired decision, failed required gate, prohibited event, unknown material control result, or open condition blocks progression. Conditional approval remains non-effective until each required condition has verified closure.

## 10. Roadmap Review and Portfolio Learning

- Weekly delivery review: [Owner, inputs, and decisions]
- Phase-gate review: [Owner, inputs, and decisions]
- Monthly outcome, risk, cost, and operating review: [Owner, inputs, and decisions]
- Incident and material-change review: [Trigger and authority]
- Business-case comparison with actual results: [Reference]
- Lessons that apply only to this workflow: [Record]
- Durable lessons proposed for governed shared context: [Proposal and review path]
- Reusable Skills or artifacts created: [References]
- Portfolio capacity, dependency, and concentration updates: [References]
- Next roadmap version or archive decision: [Decision]

Do not turn a one-time observation into must-follow Knowledge, a reusable Skill, or fleet-wide policy without the applicable evidence, review, authority, and publication process. Preserve the original roadmap and gate decisions when creating a new version.