Neither. The order form and orders list above them are real — placing an order is a genuine authenticated request against this application's own API. The deployment-detection scenarios are illustrative teaching examples: they show how an investigation would be structured once cop406-read-only-investigation is active, not a live agent call. This is the same Illustrative scenario versus Verified configuration distinction called out on the Experience tab.

Any new investigation Skill in this Agent Space starts Inactive by design, whether it targets incident triage, root-cause analysis, or any other agent type. An operator reviews its instructions against the account's real incident-response process before it can influence a live investigation. That review step, and the single toggle that activates it, are covered in the Configure the DevOps Agent tab.

No. Its Agent Types are Incident Triage and Incident RCA only — investigation and root-cause analysis, not mitigation. It can read deployment events, alarms, metrics, and logs, and recommend a fix with a rollback plan for a human to approve. It cannot deploy, roll back, or modify anything itself.

AWS DevOps Agent reads repository context and dependency relationships across the repositories connected to this Agent Space, not just the one file diff. A change that affects a downstream consumer — for example a shared API contract — can surface as a finding even though the dependent repository's own files were never touched in the pull request.

A release-readiness review typically completes in a few minutes for a change scoped to policy, architecture, and dependency evidence. Reviews that also run automated verification testing — building and exercising the code in a managed environment — take longer, closer to 8–10 minutes depending on the size and complexity of the change.

The recommendation shown here is a summary. In a real Agent Space, the complete findings — affected files, evidence, severity, and remediation steps — appear as inline comments directly on the pull request diff, with the overall recommendation posted as a single pull-request comment, and the full report available in the Agent Space Web App.

It states what it found, what it could not confirm, and why — rather than guessing. Missing evidence is treated as a finding of its own (typically Proceed with Caution), not silently ignored and not a reason to invent a result.

A Skill is something the agent decides to load based on its Description and relevance to the current task — that is why a vague Description can cause a well-written Skill to be skipped. An AGENTS.md file is a standing instruction for a specific agent type, read at the start of every matching task whether or not it looks relevant. This Agent Space uses AGENTS.md for the read-only safety boundary that must always apply to incident triage, and Skills for the situational policy and architecture guidance that only matters when it's relevant to the change.

Create or edit it with Status set to Inactive, then ask a question about it directly in DevOps Agent chat, referencing the specific scenario you want to check. Chat can load an Inactive Skill on request even though automated pull-request reviews cannot. Once you're satisfied, toggle Status to Active the same way this Agent Space activates cop406-read-only-investigation.

In this configuration, the most severe individual finding sets the overall recommendation. A single confirmed BLOCK from any active Skill is enough to block the release, even if every other Skill says Safe to Release. That is why each Skill's Instructions are written to reserve BLOCK for confirmed, no-exception violations rather than every disagreement.

No. An in-progress review keeps using the Skill content it started with. An edit — or an activation or deactivation — takes effect starting with the next review the agent runs.

No. A Skill is a Markdown document, not executable code — it tells the agent what to look for and how to weigh it. Every piece of AWS evidence still comes through the agent's own read-only investigation role, and mutative AWS operations are blocked outright during a review, regardless of what any Skill's Instructions say.

Yes, but it's generous for a setup like this one: an Agent Space supports up to 200 user-created Skills. This demo uses four assets total — the three active release-review Skills, plus the one inactive investigation Skill — well within that limit.

core-policies is explicit that an undocumented exception is not approval — but a documented one is a different story. Recording the approved exception where the agent can see it, such as in the pull request description or a linked approval record, gives it the evidence needed to reflect that context in its finding instead of treating the change as an unexplained violation.

Both, where relevant. Some checks are diff-scoped, like scanning changed lines for credential exposure. Others are resource-scoped, like the data-classification tag policy, which flags a pre-existing untagged resource as a finding even when the pull request never touches it — because the risk exists in the account regardless of which change happens to surface it.

Yes. A Skill is a Markdown document, not application code. Edit the Instructions field for core-policies in the Agent Space Web App to add or change a policy, and it applies to the next review with no redeploy. See Configure the DevOps Agent for exactly how to edit a Skill, and Learn for why Skills are written this way instead of as policy-as-code.

Policy Gate covers core-policies's no-exception rules — encryption, credential exposure, database network exposure, and required tagging. This tab groups feature-flag-code-reviews with the parts of aws-well-architected-code-reviews that also concern rollout and dependency risk — safe deployment, rollback readiness, and reliability — because those two Skills are evaluating the same underlying question: can this change be exposed gradually and reversed safely if something goes wrong.

No. feature-flag-code-reviews recommends one only when it materially reduces customer impact, limits blast radius, separates deployment from activation, or provides a faster rollback path. A small, low-risk change with no flag can still reach Safe to Release.

The review can only weigh evidence it has access to — the pull request, connected repositories, and approved read-only AWS context. A rollback plan that lives only in a private chat thread or an unlinked document is invisible to it. Referencing it in the pull request description, or keeping it in a repository the Agent Space can read, is what turns it into evidence.

Manual approval:

• Scales with the number of reviewers on your team, not with pull-request volume
• Depends on the reviewer remembering every organizational policy
• Gives no cross-repository dependency visibility

Agent-reviewed release management:

• Runs the same evidence-based check on every pull request, at agentic-coding speed
• Applies core-policies consistently — no policy is forgotten under deadline pressure
• Still ends in a human decision: BLOCK / Caution / Safe informs, it does not replace, the merge

Linters and static analysis:

• Catch syntax and style issues within a single file
• Cannot reason about cross-repository dependency risk
• Cannot weigh rollback readiness or deployment risk in plain language

AWS DevOps Agent:

• Reads the pull request, repository context, and approved read-only AWS evidence together
• Evaluates organizational policy, Well-Architected trade-offs, and rollout safety as one review
• Explains its recommendation in plain language, not just a pass/fail exit code

It is designed for GitOps speed, not against it. The review only runs when a pull request is ready for review against main or release/* — not on every draft commit. Most changes clear as Safe to Release in minutes. The goal is to match the velocity of agentic code generation without losing the safety net a human reviewer used to provide.

A rules engine (e.g. policy-as-code):

• Requires engineers to learn a policy-specific language
• Struggles to express judgment calls like "is this rollback plan adequate"
• Needs a code change and redeploy to update a policy

DevOps Agent Skills:

• Are written in plain Markdown that any engineer or policy owner can review and edit
• Can weigh nuanced, evidence-based judgment, not just pass/fail conditions
• Update instantly for the next review — no pipeline redeploy required

core-policies — no-exception checks: encryption, credential exposure, public database exposure, and required data-classification tags.

aws-well-architected-code-reviews — the six Well-Architected pillars: safe deployment, rollback, reliability, security, and cost/performance trade-offs.

feature-flag-code-reviews — safe rollout design: flag defaults, targeting, stop conditions, and partial-rollout compatibility.

Whoever owns the policy it encodes — for core-policies, that's typically security or platform engineering, not the individual pull-request author. Because a Skill is a Markdown document editable in the Agent Space Web App, that owner can update it themselves as policy changes, without filing a ticket against the application team or the pipeline.

The agent follows what the Instructions actually say, so a stale or incorrect Skill produces a stale or incorrect finding — the same risk a stale wiki page or an outdated lint rule carries. That is why a Skill's owner reviewing and versioning its Instructions matters as much as writing them in the first place; it is also why cop406-read-only-investigation stays Inactive here until that review has actually happened.

An agent that can both find and silently fix a security or infrastructure issue has a much larger blast radius if it is wrong. AWS DevOps Agent is scoped to read, describe, and evaluate — it does not deploy, modify, or delete resources during a review. That boundary is what makes its recommendation trustworthy enough to act on quickly.

• Merging the pull request itself
• Approving an exception to a no-exception policy
• The final GitOps promotion to a production environment

Built-in guardrails run underneath every review, independent of what any Skill says. The agent blocks any tool call whose input contains a plaintext credential pattern — an AWS access key, a token, a private key — and it blocks shell commands that combine access to sensitive file paths with a network operation, the classic shape of an exfiltration attempt. A Skill's Instructions cannot override either guardrail.

A GitHub webhook event for the connected repository — the pull request being opened, or a new commit pushed to it — reaching a target branch that matches this Agent Space's trigger filter. This demo's filter also restricts it to the Pull request ready for review event, so pushing commits to a draft pull request does not start a review; converting it to "ready for review" does.

Not automatically. Automated pull-request review triggers are only available for private repositories, because anyone can open a pull request against a public one — including unknown external contributors — and auto-triggering a review on those would consume resources and process untrusted content without the repository owner's awareness. On a public repository you can still request a review on demand through DevOps Agent chat or a coding-agent integration.

That capability provisions a managed environment, clones the change into it, and actually builds and exercises the code — genuinely useful, but it adds several minutes and needs outbound network access rules of its own. This demo keeps it off so a review stays fast and focused on the policy and architecture decision that AWS DevOps Agent Release Manager is teaching. A real Agent Space can turn it on per repository at any time.

No — GitLab is also a supported pipeline provider, connected and configured the same way. This Agent Space only registered a GitHub connection because this demo's repository lives on GitHub.

Ask about it directly. You can follow up in DevOps Agent chat with a question like "Why did the review flag the IAM change in line 42?" and get the reasoning behind that specific finding. The recommendation still only informs the merge — a human reviewer can merge past a Caution finding they've evaluated and accept, the same way they always could past a human reviewer's comment.

If a review is configured as a required status check and it never completes, the merge simply waits, the same way it would for a stuck CI job — the pull request is not silently approved. If a review appears to be missing entirely, first check that the pull request's target branch actually matches the connection's trigger filter, and that "Auto trigger change review" is still enabled for that repository.

Yes. You can request one on demand through DevOps Agent chat — for example "Review branch feature/payments on repo payment-service for release risks" — or have a coding agent (the Kiro Power or Claude Code plugin) trigger one while code is still being written, before a pull request even exists.