Software request reviewer for IT approvals

I want an agent workflow that reviews software and tool requests coming into my IT team and prepares each one for a human approval decision. It should never auto-approve anything; it should hand back a clean draft and let an IT lead make the final call.

Trigger: run when a new software request lands in one of these intake spots, whichever I have set up: a new message or thread in a designated Slack channel (for example #it-requests), a new message in a Microsoft Teams channel, or a new Linear or Jira issue tagged as a software request. I should also be able to invoke it on demand against a pasted note.

What the agent should do, in order:

1. Pull the full request context. If it's a Slack thread, read the parent message and all replies. If it's a Microsoft Teams channel message, pull the message and its replies. If it's a Linear or Jira ticket, read the description and comments. Capture who is requesting, what tool they want, the use case, team, urgency, and any data the tool would touch.

2. Look up our approved software catalog and IT policy docs. These live in Notion pages or databases, in Google Drive files, and in Microsoft SharePoint sites. Search them for the requested tool name, the category (for example 'note-taking', 'CRM', 'AI coding assistant'), and any policy that applies to that category (data classification rules, vendor security review, SSO requirement, procurement thresholds).

3. Compare what the requester is asking for against what we already pay for or have approved. If we already own a tool that covers the same job, call that out as the preferred alternative with a short reason. If the tool itself is already on the approved list, say so up front.

4. Run a gap and risk check across these dimensions and write a short finding for each one: security (vendor SOC2, SSO support, known incidents), data handling (what data the tool would access, classification, residency), procurement (cost, contract length, who owns the budget), legal (DPA, terms of service issues), and ownership (who inside the company will own the relationship and renewals). Flag explicitly what information is missing from the request and would need to be answered before approval.

5. Decide a recommendation: approve, approve with conditions, decline, or pending info. Conditions should be specific (for example 'requires SSO enabled before rollout', 'limit to the design team', 'use the existing Figma license instead').

6. Draft two outputs:

a. A short, friendly follow-up message back to the requester. If the request came in via Slack, draft a Slack reply in that thread; if via Microsoft Teams, draft a Teams channel reply. The message should ask only for the gaps that actually matter, point them at any approved alternative, and set expectations for next steps. Do not include sensitive pricing, license keys, or vendor security report contents in this public reply.

b. A tracker-ready review ticket. Create an issue in Linear (or Jira, depending on which I've connected) in my IT review project. The ticket should include: requester and team, the requested tool and use case, the recommendation, conditions or follow-up questions, security and data findings, suggested alternatives, links back to the original Slack thread or Teams message, and links to the policy or catalog docs the agent referenced. Assign it to the IT reviewer on rotation.

7. Post the drafts for me to review before anything goes out. The Slack or Teams follow-up should be queued as a draft I can edit and send; the Linear or Jira ticket can be created directly since it's internal.

Tone for the requester-facing draft: helpful and collaborative, not gatekeeping. Acknowledge their goal, explain why we're checking what we're checking, and make the next step obvious. Keep it short.

Be careful with sensitive information. License keys, vendor pricing, internal security review notes, and seat allocation belong in the tracker ticket only, never in public Slack or Teams replies.