How do I let a customer trigger their agent from their own systems?

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

#The question

If you are asking "How do I let a customer trigger their agent from their own systems?", you want entry points you declare instead of endpoints you build. The short answer: declare webhooks, forms, and schedules in the .swirls files. The customer's systems call the webhook, their people use the form, and the schedule runs on its own.

#Who's asking

Forward-deployed / solutions engineer. Built the agent, and now the customer's CRM, ticketing system, or back office needs to kick it off without anyone building integration glue.

#Why Swirls is a fit

Triggers are declarations, not infrastructure. A webhook block gives the customer's systems a URL to call, a form block gives their people a hosted entry point, and a schedule block covers recurring runs. All of it ships in the same deploy as the agent.

Inputs are typed. Trigger payloads validate against declared schemas before any agent logic runs, so malformed calls from the customer's side fail loudly at the boundary instead of misbehaving downstream.

Every triggered execution is attributable. The audit chain records what fired, what ran, and what the agent did with it, which is exactly the answer you need when the customer asks why something happened.

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.