How do I kick off an agent when an email hits my support inbox?

Put the process in sourcesteps and decisions declared
Keep the trigger, action, failure policy, and review point in one project.

#The question

"How do I kick off an agent when an email hits my support inbox?" comes down to giving an agent a real operational story. Swirls does that by making the agent a deployable artifact: declare it in .swirls files and ship it with git push or swirls deploy.

#Who's asking

Technical operator automating a process. "My boss tasked me with automating this." Not scared of a config file, ships small wins and grows them.

#Why Swirls is a fit

Anything can start a run. Webhooks and cron schedules are declared in a .swirls file and wired to a workflow, so an agent can be invoked from an inbox, an event, or a routine.

Your app becomes a thin consumer: a session id, a trigger, a response. Prompt assembly, tool calls, schedules, and audit move out of application code and into a deployed Swirls project.

Add the people, data, authority, and decisions around this job.

Keep this solution beside the Apps, records, rules, connections, and reviews it depends on in one .swirls project.