Skip to content

Week 9 Reflection: Can a Team Trust This?

This week moved from capability to judgment. You already know how to build agents, skills, commands, workflows, and MCP integrations. The production question is different: should other people trust them?

Use this reflection after completing Lab 9.1 and Lab 9.2.

Part 1: Permissions

Pick one agent you worked on this week.

Answer:

  1. What is this agent's one job?
  2. Which permission was easiest to justify?
  3. Which permission was hardest to justify?
  4. If this agent caused damage, what is the most likely way it would happen?
  5. What permission would you change before sharing it with a team?

Write 5-8 sentences.

Part 2: Cost and Context

Think about one prompt you gave an agent this week.

Answer:

  1. Did the agent need all the context you gave it?
  2. What could you have removed?
  3. What path, file, or output limit would have made the prompt sharper?
  4. Did the agent produce more output than you needed?
  5. How would you rewrite the prompt now?

Use this format:

Original prompt:

Problem with it:

Improved prompt:

Part 3: Evals

Review the five evals you wrote.

Answer:

  1. Which eval gave you the most useful signal?
  2. Which eval was too vague?
  3. What did a failed or weak eval teach you?
  4. What behavior still needs an eval?
  5. If you changed the model tomorrow, which eval would you run first?

Good evals make expectations visible. If one of yours felt hard to judge, rewrite it with clearer failure conditions.

Part 4: Secrets

Answer honestly:

  1. Have you ever pasted a key, token, .env value, or private data into an AI tool?
  2. If yes, what should you have done instead?
  3. If it happened in a real team setting, who would need to know?
  4. What is your personal rule for handling secrets with agents?

Write your rule as one sentence.

Example:

I will share environment variable names and error messages with agents, but never secret values.

Part 5: MCP Supply Chain

Choose one MCP server from Week 8 or from a peer config.

Answer:

  1. What system does it connect to?
  2. What credentials does it need?
  3. Can it read data, write data, or both?
  4. Is the version pinned?
  5. Who maintains it?
  6. What would make you comfortable approving it for team use?

If you cannot answer these questions, the MCP server is not ready for production use.

Part 6: Team Adoption

Imagine you are introducing OpenCode to a team of five developers.

Design the first shared workflow.

Answer:

  1. What is the workflow?
  2. Why is it safe enough to start with?
  3. Which agent would you share first?
  4. What permissions would it have?
  5. What evals would you require before rollout?
  6. What rule would you put in AGENTS.md?

Keep the first workflow small. The best first team workflow is usually boring: docs cleanup, test summarization, changelog drafting, or read-only code review.

Final Prompt

Complete this sentence:

Before I trust an agent in production, I need evidence that it...

Write 3-5 endings.

Examples:

  1. Respects permission boundaries.
  2. Does not ask for secrets.
  3. Handles bad input without inventing facts.
  4. Keeps context focused.
  5. Has evals that catch regressions.

What to Bring Into Week 10

Bring these artifacts to the capstone:

  1. One hardened agent.
  2. Five eval prompts.
  3. One security review report.
  4. Your secret-handling rule.
  5. Your MCP review questions.

Week 10 will combine everything: agents, subagents, MCP, permissions, evals, and human review into one PR review pipeline.