The situation

A developer opens a fresh agent session to add coverage for a payment flow. The agent has never seen this project. It does not know that “member” and “seat” mean different things here, that the staging environment resets nightly, or that a sandbox card number must never appear in a case title.

What the agent does

  1. Calls list_projects and resolves the one it may write to, then get_field_options to learn the valid priorities, types and statuses instead of guessing them.
  2. Calls get_project_rules: human-curated roles, environments, naming conventions and domain constraints, written once and read by every agent that follows.
  3. Calls get_project_lessons: incidents that already happened, each with the class of failure to watch for. One lesson says duplicated cases were created last quarter because nobody searched before authoring.
  4. Searches first—smart_search_cases, then find_related_cases—and reads the matches in full before drafting anything.
  5. After the work is approved, leaves something behind: a new rule with create_project_rule when it learned a durable fact, a lesson with create_project_lesson when something went wrong.

What the human reviews

The rules and lessons themselves. They are short, atomic and editable in the product, so the QA Engineer curates what agents are told rather than repeating it in every prompt.

Why it works

Context that lives in chat history disappears with the session. Context that lives in the vault is retrieved through the same MCP as the cases, by whichever agent comes next. The tool atlas below shows the surface those agents work with.