Alex: Welcome back. Challenge 15 is Meet the Agents, and it moves us into the capstone project space without asking you to build anything yet.

Jamie: So this is the moment where learners meet Gandalf's peers, but they are not expected to become agent engineers in one sitting.

Alex: Exactly. Your job is to explore the Community-Access accessibility-agents repository, discover what agents exist, run one carefully, and read one agent's instructions file. The real skill is learning how to inspect an AI tool before you trust it.

Jamie: And an important detail: this challenge is browse-first. You are not required to fork the accessibility-agents repository just to complete Challenge 15.

Alex: Right. The Accessibility Agents collection is a living catalog, so do not memorize a fixed list. It is organized around teams like Accessibility, GitHub Workflow, and Developer Tools, and agents can appear in different environments, including GitHub Copilot in VS Code and other supported platforms.

---

Jamie: Before anyone opens Copilot Chat and starts summoning agents, what should already be in place?

Alex: For Day 2, VS Code is the supported editor, and you should have GitHub Copilot access working. Copilot Free is enough for the workshop path. If you joined Day 2 without Day 1, use the Day 2 Quick Start to confirm your account, tools, and basic GitHub workflow skills.

Jamie: Because Day 1 was where people did the regular GitHub work by hand, right? Issues, branches, commits, pull requests, review, and merge in their provisioned Learning Room repository.

Alex: Yes. Agents are useful only when they build on a skill you already understand manually. If an agent reviews a pull request, you should already know how to read a diff. If an agent summarizes issues, you should already know what a useful issue looks like.

Jamie: That makes the agent less like a shortcut and more like a power tool. You still need to know what safe and correct looks like.

Alex: Exactly. If you cannot do the task by hand yet, slow down and learn the manual workflow first. Then the agent can help you move faster without replacing your judgment.

---

Jamie: So where do we start in the actual challenge issue?

Alex: Open the Community-Access accessibility-agents repository on GitHub. Read the README first, because it explains how the catalog is arranged and how individual agents are meant to be used. Then browse the folders, where each agent has its own files and usually its own instructions.

Jamie: The challenge asks for at least three agents and what they do. What would count as a good discovery note?

Alex: You might find `@accessibility-lead`, which coordinates accessibility reviews and can route work to specialists. You might find `@aria-specialist`, which looks at ARIA roles, states, and properties in HTML or web components. You might find `@keyboard-navigator`, which focuses on tab order, focus management, keyboard shortcuts, and whether interactive elements can be operated without a mouse.

Jamie: Quick definition check. ARIA is Accessible Rich Internet Applications, the set of attributes that can help assistive technology understand custom interface behavior.

Alex: Yes, and it is powerful but easy to misuse, which is why a specialist agent can be useful. You can also explore GitHub Workflow agents such as `@daily-briefing`, `@issue-tracker`, `@pr-review`, `@analytics`, `@insiders-a11y-tracker`, and `@template-builder`. Some agents are informational, some can help with tasks, some guide you through a workflow, and some coordinate other agents.

Jamie: What if the catalog has changed by the time someone listens to this?

Alex: Use the repository README as the current map, and use Chapter 19 for the learning frame. If the agent schema itself is confusing, you can mention `@gandalf-bot` and ask: How does the agent schema work?

---

Jamie: Running an agent is the part that can feel a little risky. What is the careful version?

Alex: Choose one agent that matches a skill you already have, then read that agent's README or usage notes. It may run through a Copilot Chat command, a VS Code palette command, an Agents window session, or another documented path. Start with a small file or a small question, not a high-stakes repository-wide change.

Jamie: So a learner might ask something like `@daily-briefing morning briefing`, or `@issue-tracker find open issues labeled good-first-issue`, depending on what the agent supports.

Alex: Yes. Another example is asking `@accessibility-lead` to review the heading structure of a file. In the solution example, the lead agent routed that request to a heading specialist, which noticed a jump from H2 to H4.

Jamie: But the learner still needs to check the file. The agent's answer is not automatically true just because it sounds confident.

Alex: Exactly. Read the output, compare it with what you expected, and verify against the file, issue, pull request, or accessibility rule. The challenge evidence should say what the agent did and whether that matched your manual understanding.

Jamie: And these agents can show up in more than one place, right?

Alex: Right. The workshop path is strongest in VS Code with Copilot Chat, and GitHub.com can also support Copilot workflows such as task mode, PR summaries, PR review help, and issue conversations. GitHub Desktop, the `gh` CLI, and `gh copilot` can support repo movement and command help, but you still inspect commands before running them. Other platforms may support the same catalog through their own setup paths, so follow the instructions for the platform you are actually using.

---

Alex: The most useful file to read is an agent's `.agent.md` file.

Jamie: Those files can look strange at first because they mix configuration and plain-language instructions.

Alex: At the top, you will usually see YAML frontmatter. YAML is a readable configuration format, and the frontmatter can name the agent, describe it, and limit which tools it may use. Below that, the body explains the agent's purpose, responsibilities, output style, and guardrails.

Jamie: Guardrails are the boundaries. They tell you what the agent should not do, or what it cannot know reliably.

Alex: Yes. For example, `@keyboard-navigator` can review code for keyboard accessibility patterns, but it cannot physically press Tab through an app and prove the behavior works. A human still needs to test actual keyboard interaction.

Jamie: Appendix L goes much deeper than this challenge needs, but it helps explain the file ecosystem.

Alex: It does. You will see always-on instructions like `.github/copilot-instructions.md`, file-based `.instructions.md` rules, `.prompt.md` slash commands, reusable `SKILL.md` files, hooks for lifecycle automation, and `preferences.md` for personal settings. The big idea is that agents are configurable tools with scope, priority, permissions, and limits.

Jamie: So a good first read is not every line. It is frontmatter, purpose, responsibilities, guardrails, and then any examples that show how to invoke the agent.

---

Alex: Once you have explored, run, and read, document what happened.

Jamie: The challenge gives two paths for notes: use the local clone from earlier Day 2 work, or edit through GitHub if that is the better route.

Alex: Open `docs/my-notes/agents-discovery.md` in the repository where the challenge asks you to work. Add a section with your username, three agents you found, the agent you ran and what it did, and the agent file you read with its purpose and guardrails.

Jamie: And if someone is working locally, this is a normal Git workflow again.

Alex: Yes. Add the file, commit with a message like `docs: add agent discoveries for your-username`, push your branch, and open a pull request. If you are using the GitHub editor, the web flow still needs a commit and a shareable PR or commit URL.

Jamie: Then the issue's evidence box asks for the same story in a compact form: three agents, one run, one instruction summary, and the PR or commit link.

Alex: Right. There is also a peer simulation check. Compare your discoveries with the simulated peer issue, or with a real buddy if you have one, because different people may find different agents and different use cases.

---

Jamie: What happens when Challenge 15 is closed?

Alex: Closing Challenge 15 unlocks Challenge 16, titled Capstone Project, plus Bonus Challenges A through E. Those bonus challenges are part of a structured unlocked path, not leftover extras.

Jamie: And the capstone is flexible. It is not only about one repository.

Alex: Correct. Challenge 16 can accept meaningful contributions to Accessibility Agents, GLOW, or another repository where your work matters. A review-ready draft or a clear contribution plan can count as valid evidence, because planning a responsible contribution is real work.

Jamie: There is also a feedback task called out in Chapter 19.

Alex: Yes. Share workshop feedback when asked. It helps improve the learning path, the agent catalog, and the accessibility of the whole experience.

---

Jamie: Let's do quick troubleshooting, because this is where learners can lose momentum.

Alex: If you cannot find the repository, go to the Community-Access organization and search for accessibility-agents. If you do not know how to run an agent, open that agent's folder and look for its README or usage examples. If the `.agent.md` file feels overwhelming, read the YAML frontmatter first, then jump by headings to purpose, responsibilities, and guardrails.

Jamie: What if the agent gives a weird answer, or an answer that disagrees with what the learner sees?

Alex: Treat that as a signal to verify, not as a failure. Check the source file, narrow your prompt, confirm the agent had the right tools and repository context, and compare the result with your manual knowledge. If an agent is not found, check the file location, reload the editor or Copilot session, and confirm the customization format your platform supports.

Jamie: What references should people keep open while they work?

Alex: Chapter 19 is the guided lesson for this challenge, and Appendix L is the detailed reference for agents, instructions, prompts, skills, hooks, preferences, scopes, and troubleshooting. When platform behavior changes, use the official GitHub Copilot and VS Code documentation as the current source for product details.

Jamie: So the win is not proving that an agent is amazing. The win is being able to say what it is, what you asked it to do, what it produced, and where its limits are.

Alex: Exactly. Find three, run one, read one, document your evidence, and close the issue when your work is ready. Then you are prepared to move into the capstone path with better judgment about when AI help is useful and when human review still leads.