Engineering and product scenarios

People want to know which tickets to focus on today, either by asking or by receiving a morning summary.

Choose the version that fits:

1. On request. An employee asks in Copilot. An agent with live Jira access finds the active tickets, ranks them against the team's rules, and returns a short, ranked list.
2. Every morning. A scheduled Loop asks a Jira-connected agent to fetch and rank current tickets. The Loop AI formats the list if needed, and an email step sends it. The run history records each send.

Ticket status changes constantly, so it must be read live. A schedule turns a useful question into a habit nobody has to remember.

• How does this team define priority?
• Which owners, statuses and severities matter?
• Are there ticket types where age is normal?

• Assuming oldest-first is right. A 90-day-old ticket can be perfectly normal for some types. Use the team's rules, with their exceptions.
• Treating a sent email as delivered. See Loops and outbound.

Developers ask questions about a codebase that has several active branches or historical versions.

1. Import selected repositories and branches into separate, clearly labelled knowledge folders.
2. A code support agent searches that knowledge to understand structure.
3. Optional live repository access fetches current files, paths or differences.
4. Answers always state which repository and branch they refer to.

Code changes too often to retrain on every commit. Periodic imports give the agent a map; live access gives it the current detail.

• Which repositories and branches are authoritative?
• Is code access for internal users only?
• How often does each branch change?
• Should the agent compare versions, or default to the main branch?
• Are there restrictions on exporting source code?

• Blending versions. Test by asking about the same function in two branches and checking the answers stay separate.

When support marks a ticket as a bug, the team wants to know whether engineering already has an issue for it.

1. Marking the ticket as a bug fires a webhook that starts a Loop.
2. An agent with access to both the CRM and Jira searches open and known issues and compares them.
3. If it finds a match, it links the issue and adds a note to the original ticket.
4. If it doesn't, it drafts a new bug report.
5. A person approves the draft, or sends it back for revision.
6. On approval, the agent creates the Jira issue and updates the ticket.

Searching first prevents duplicate bugs. The approval step keeps engineering's backlog clean.

• Creating duplicates. Always search before creating.
• Missing evidence. Branch three ways: match found, no match, or not enough information.
• Crossing permission lines between customer cases and engineering projects. Log every record that changed.

The product team wants a weekly page of changes, built from closed Jira tickets or repository changes.

1. A weekly schedule starts a Loop.
2. An agent with Jira or repository access gathers changes since the last run.
3. It writes customer-friendly highlights.
4. The Loop AI formats them, if needed.
5. An editor approves or sends back the draft.
6. On approval, the draft is saved to the content system through an authorized tool, or delivered for someone to publish.

The agent does the gathering and first draft; a person decides what's announced.

• What period does each changelog cover?
• Which statuses count as shipped?
• Which items are behind feature flags or not yet public?
• Who approves?

• Announcing every closed ticket. Not everything that's finished is ready to be public.
• Assuming a publishing tool exists. Confirm the content system integration before designing around it.

Someone working in Claude or another assistant needs relevant CRM records or meeting transcripts, without loading large amounts of raw data into an expensive model.

1. The assistant calls a raia agent exposed as an MCP server.
2. That light "gopher" agent uses its own integrations to retrieve records or transcripts.
3. It filters and consolidates them into a compact answer with sources.
4. The assistant's stronger model reasons over the compact answer.

Inexpensive retrieval and filtering happen on a light model, saving the expensive model for reasoning. See Cost and model choice.

• Losing sources or uncertainty in the summary. Keep both.
• Over-compressing. Allow follow-up requests when something was left out.
• Bypassing permissions. The gopher should retrieve only what the person is allowed to see.