AI SDLC Certification Prep: Agent Memory, Evaluation, Autonomy, and Governance

• Agent memory strategies
• The memory hierarchy
• Choose where to store information
• Scope memory to relevant information
• Memory expiration and pruning
• Persist agent state
• Pull requests as state anchors
• Resume work without repeating steps
• Detect and correct context drift
• Continuity across tools and environments
• Define evaluation signals
• Enforce quality gates
• Use workflow outputs for visibility
• Analyze agent failures
• Classify root causes
• Risk-based autonomy
• Autonomy levels
• Risk classification model
• Route execution based on risk
• Enforce governance with GitHub controls
• Required checks and ownership
• Human-in-the-loop workflows
• Least privilege
• Make actions observable and auditable
• Maintain governance over time
• Governance failure patterns
• Final exam checklist
• Series recap

Agent systems need more than task execution. They need memory, durable state, evaluation signals, autonomy boundaries, least privilege, human oversight, auditability, and continuous governance.

This final post in the series brings those operational pieces together.

Agent memory strategies

Agents need structured memory to complete tasks reliably. Instead of relying on a single stream of context, memory should be organized so the agent can focus on the current task while still accessing important information when needed.

The memory hierarchy

In GitHub, external memory includes issues, pull requests, documentation, workflow outputs, and artifacts. External memory is usually the strongest source of truth because it is persistent and reviewable.

Choose where to store information

Different information belongs in different places.

Avoid storing critical information only in prompts or chat history. If it matters for the outcome, put it in a durable GitHub artifact.

Scope memory to relevant information

Memory should be limited to information that affects the outcome of the task.

Relevant memory includes:

• requirements and constraints,
• decisions that affect implementation,
• validation and testing approaches,
• known risks and escalation paths.

Do not retain temporary intermediate thoughts or duplicated context unless they affect future decisions. Too much memory creates stale-context risk.

Memory expiration and pruning

Memory should be maintained over time.

In GitHub:

• workflow logs and artifacts are retained for a limited period,
• retention can be configured at repository, organization, or enterprise level,
• public repositories commonly support shorter retention ranges than private repositories,
• deleted artifacts cannot be restored.

Prune outdated artifacts, summarize long histories, and reset context when requirements change significantly.

Persist agent state

Memory helps an agent understand what matters. State tracks what has been done, what decisions were made, and what remains.

In GitHub workflows, state is represented through:

• issues,
• pull requests,
• commits,
• workflow runs,
• checks,
• logs,
• artifacts.

These artifacts allow the agent or reviewer to resume work without starting over.

Pull requests as state anchors

A pull request should include:

• a clear task description,
• acceptance criteria or a link to the issue,
• a summary of the plan,
• updates when decisions change,
• references to commits and workflow runs.

GitHub aggregates commits, checks, and discussions in the pull request, making it the main place to track progress and decisions.

Resume work without repeating steps

A safe resume flow is:

1. Open the existing pull request.
2. Review the PR description and linked issue.
3. Check commits already made.
4. Review workflow results under the Checks tab.
5. Continue from the latest verified state.

This prevents duplicate work and keeps the agent aligned with current repository state.

Detect and correct context drift

Context drift occurs when agent actions no longer align with the original goal or prior decisions.

Detect drift by checking:

• whether PR changes satisfy acceptance criteria,
• whether commits contradict earlier decisions,
• whether workflow checks are failing or missing,
• whether the branch is stale relative to the base branch.

Correct drift by re-reading the source of truth, comparing changes against acceptance criteria, updating the PR description if needed, and rerunning workflows.

Continuity across tools and environments

Agent workflows often span IDEs, CLIs, GitHub-hosted environments, and web UI. Continuity depends on durable references, not copied chat context.

Use:

• pull request numbers,
• branch names,
• commit SHAs,
• workflow run links,
• issue and PR URLs.

When switching environments, always re-anchor to GitHub state.

Define evaluation signals

Evaluation begins with clear success criteria. In GitHub workflows, those criteria should live in the issue or pull request.

Examples:

• A feature behaves as expected.
• Tests pass.
• No new security issues are introduced.
• Scope matches the plan.
• Evidence is present.

Use pull request checks for evaluation. GitHub displays status checks, workflow runs, and check results directly in the PR.

Enforce quality gates

Quality gates should be enforced with required checks, not only documented expectations.

Common workflow validations include:

• tests,
• linting,
• builds,
• code scanning,
• dependency review,
• secret scanning and push protection.

on:
  pull_request:
    branches: [main]

Branch protection or rulesets can require specific checks before merge.

Use workflow outputs for visibility

Workflows produce logs and artifacts that support evaluation.

Reviewers should be able to access:

• test results,
• scan reports,
• plan files,
• execution reports,
• workflow run links.

Treat missing evidence as a failure. If a change cannot be audited, it should not be merged.

Analyze agent failures

Agent workflows do not always succeed on the first attempt. Failures can come from incorrect assumptions, tool misuse, or stale context.

Analyze failures using:

• workflow logs,
• PR changes and discussions,
• commit history,
• workflow run results,
• uploaded artifacts.

Compare intent with results:

Classify root causes

Improve behavior by updating prompts, repository instructions, durable memory, workflows, permissions, or required checks.

Risk-based autonomy

Risk-based autonomy means allowing agents to act within boundaries that match the impact and reversibility of their actions.

Low-risk tasks can run with more automation. Higher-risk actions require validation, approvals, and stricter controls.

Risk depends on:

• where the change is applied,
• how easily it can be reversed,
• how quickly it affects users or systems,
• whether it touches secrets, infrastructure, deployment, or workflows.

Autonomy levels

Autonomy is not one setting. It is a combination of PR rules, environments, workflow permissions, tool access, and review policy.

Risk classification model

Treat changes to .github/workflows/, infra/, and security/ as high risk by default. These are often small diffs with big consequences.

Route execution based on risk

Use machine-readable signals instead of relying only on narrative explanations.

name: agent-plan-apply

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  plan:
    runs-on: ubuntu-latest
    outputs:
      risk: $
    steps:
      - uses: actions/checkout@v4
      - name: Download plan artifact
        uses: actions/download-artifact@v4
        with:
          name: plan
          path: out
      - id: read
        name: Read risk from plan.json
        run: echo "risk=$(jq -r .risk out/plan.json)" >> "$GITHUB_OUTPUT"

  apply_auto:
    needs: plan
    runs-on: ubuntu-latest
    if: $
    steps:
      - name: Apply low-risk plan
        run: ./scripts/apply.sh out/plan.json

  apply_with_approval:
    needs: plan
    runs-on: ubuntu-latest
    environment: approval-required
    if: $
    steps:
      - name: Apply approved plan
        run: ./scripts/apply.sh out/plan.json

Enforce governance with GitHub controls

GitHub governance controls include:

• rulesets and branch protection,
• required checks,
• CODEOWNERS,
• environments,
• guardrail workflows,
• workflow permissions,
• tool allowlists.

For protected branches such as main, enforce:

• pull request required to merge,
• required status checks,
• required approving reviews,
• CODEOWNERS review for sensitive paths,
• restricted direct pushes,
• blocked force pushes and branch deletion.

Required checks and ownership

Required checks should map to governance goals:

Treat renaming or removing required checks as high risk. If checks drift, governance drifts.

CODEOWNERS should route sensitive areas:

/security/          @security-team
/infra/             @platform-team
/.github/workflows/ @platform-team
*                   @core-team

Make sure CODEOWNERS review is required; otherwise it is advisory.

Human-in-the-loop workflows

Human oversight should be applied where judgment matters most.

Important decision points include:

• merge,
• production deployment,
• workflow changes,
• infrastructure changes,
• secret access,
• high-risk tool use.

Example production environment gate:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - run: ./deploy.sh

Prevent overlapping production deployments:

concurrency:
  group: production
  cancel-in-progress: true

Least privilege

Least-privilege execution means agents get only the minimum permissions required for the task.

Set minimal workflow defaults:

permissions:
  contents: read

Elevate permissions only in the job that needs them:

permissions:
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Read-only analysis"

  update_artifacts:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - run: echo "Write operations happen here"

Granting pull-requests: write should be treated as elevated capability.

Make actions observable and auditable

Every meaningful action should produce:

• PR and commit history,
• workflow results with job logs,
• uploaded artifacts,
• approval and merge events,
• environment approval records for production.

Evidence-first workflows should output artifacts such as:

• test results,
• scan reports,
• plan.json,
• execution reports.

- name: Upload execution report
  uses: actions/upload-artifact@v4
  with:
    name: execution-report
    path: report.json

A practical rule: missing evidence equals failure.

Maintain governance over time

Governance is not static. Controls degrade as systems evolve.

Governance drift can happen when:

• checks are renamed or removed,
• review requirements are relaxed,
• CODEOWNERS become outdated,
• permissions expand,
• secrets move into broader scopes,
• bypass paths appear.

Recommended cadence:

• Weekly: review failed runs and common policy violations.
• Monthly: review workflow permissions and secret scopes.
• Quarterly: audit rulesets, CODEOWNERS, environment reviewers, and evidence retention.

Governance failure patterns

Final exam checklist

Remember these points for the certification exam:

• Store requirements, plans, decisions, validation rules, and results in durable GitHub artifacts.
• Use pull requests as state anchors.
• Detect context drift by comparing PR changes against acceptance criteria and prior decisions.
• Enforce evaluation with required checks and security signals.
• Analyze failures through logs, PRs, commits, workflow runs, and artifacts.
• Match autonomy to risk and reversibility.
• Use GitHub controls: rulesets, required checks, CODEOWNERS, environments, guardrail workflows, and least privilege.
• Apply human oversight at merge, deployment, secret access, and other high-impact decision points.
• Treat missing evidence as a failure.
• Review governance continuously because controls drift over time.

Series recap

Across the five posts, the core model is consistent:

1. Agents can perform work, but humans remain accountable.
2. Pull requests are the main unit of review and control.
3. Workflows provide validation, evidence, and execution boundaries.
4. MCP expands capability, so registries and allow lists matter.
5. Multi-agent systems require orchestration, isolation, and conflict handling.
6. Memory and state should live in durable GitHub artifacts.
7. Autonomy must be risk-based, least-privileged, observable, and governed continuously.

That is the foundation for operating agentic AI safely in the GitHub SDLC.