Putting together the same project update every Friday. Reviewing open requests each morning. Preparing next steps after a CRM change. These tasks do not need a fresh chat every time. An AI agent can do the preparation at a scheduled time or after an event. What matters is not just when it starts, but where its work stops.
The following five workflows are starting points for a limited pilot, not preconfigured integrations. They require suitable data sources and approved tools. The agent initially produces a summary, recommendation, or draft. Publishing, sending, and binding decisions stay with a responsible person. An automatic start is not automatic approval.
Schedule or webhook: what starts the agent?
A schedule suits recurring work: daily, weekly, monthly, or with a custom cron expression. In yeos, you save the question the agent should answer on each run and choose the time and timezone. A webhook suits events: an external system sends a JSON request to a protected URL, for example after a ticket or CRM change. yeos passes that data to the agent as context. The trigger alone neither connects a business system nor grants additional access.
1. Prepare the weekly project report
Trigger: every Friday before the status meeting. The agent reads approved project sources, such as Jira tickets and project notes, and prepares a report covering progress, blockers, open decisions, and sources. Missing or conflicting information stays visible rather than being silently filled in.
- Example question: “Prepare the weekly status for Project Alpen using approved sources from the last seven days. Cite the source for each claim and flag missing information. Do not publish anything.”
- Review point: The project lead checks status, responsibilities, and deadlines before sharing the report.
- Boundary: Read-only tools are enough for this pilot. Automatically posting to Teams or Slack is out of scope.
2. Prepare a daily inbox triage
Trigger: each working morning, using a custom cron schedule if needed. The agent summarises relevant messages from the approved mailbox, suggests priorities, and prepares reply drafts where useful. The day starts with a work list rather than an unstructured collection of messages.
- Example question: “Summarise new customer requests since yesterday. Suggest a priority with reasons and prepare a reply draft for straightforward standard questions. Do not move or delete messages.”
- Review point: A responsible person checks priorities, recipients, statements, and any commitments before sending.
- Boundary: Built-in Outlook tools create outgoing messages only as drafts; none of these tools sends email. Attachment access provides metadata, not file contents. Check the capabilities of other connectors separately.
3. Prepare a monthly compliance checklist
Trigger: monthly before the internal review. Using selected policies, action lists, and documented deadlines, the agent prepares a checklist: what is due, which evidence is missing, and where is ownership unclear? This is preparation for the responsible specialists, not an automated legal review or proof of compliance.
- Example question: “Prepare a checklist for the coming month from approved policies and action lists. Include the deadline, documented owner, and source. Do not invent obligations, and flag missing evidence.”
- Review point: Compliance owners assess whether information is current and applicable, and decide what action is required.
- Boundary: Without current, complete sources, the agent cannot produce a complete list. It changes neither policies nor action status.
4. Enrich new support tickets with relevant knowledge
Trigger: The ticketing system reports a new request through a webhook. The request contains only the necessary context, such as a ticket ID, category, and description approved for processing. If the agent needs more information, an appropriate read-only tool must be configured separately. It searches relevant knowledge articles and prepares suggestions for categorising and handling the request.
- Output: An internal summary with sources, open questions, and a suggested reply in the run conversation.
- Review point: The support team checks the classification and transfers useful suggestions into the ticket.
- Boundary: A webhook does not automatically write results back into the ticketing system. Keep tools that close, assign, or reply to tickets disabled for the initial pilot.
5. Draft a follow-up after a CRM change
Trigger: The CRM reports a defined stage change, such as “Meeting completed”. Using the record ID and approved context, the agent prepares a meeting summary, open questions, and follow-up text. Access to additional CRM information requires a separately configured connector or an approved API tool.
- Output: A draft with evidenced discussion points and suggested next steps; unknown prices or dates remain explicitly unresolved.
- Review point: The responsible salesperson checks recipients, terms, and commitments and sends the message themselves.
- Boundary: The pilot does not change deal stages or create binding offers. Filter triggering events in the source system so that your own changes do not start a loop.
Set up your first automatic run in yeos
- Prepare the agent: Choose a narrow task, appropriate sources, and only the required tools. Test the task manually first, including cases with missing or conflicting data.
- Create a schedule: As an organisation admin, open the agent and Scheduled Runs. Select Create schedule, enter a name and question, choose the recurrence, time, and timezone, and initially save it as Paused until review is complete.
- Alternatively, create a webhook: Open Webhook Triggers and Create webhook. Save the trigger and copy the secret, which is displayed only once, along with the Invoke URL. Store both securely in the sending system.
- Secure the webhook request: Send JSON with Content-Type application/json and preferably the X-Yeos-Webhook-Secret header. yeos also supports a secret query parameter; avoid it where possible because URLs can appear in logs. Never share real secrets in prompts or blog examples.
- Activate under supervision: Inspect the first run in the history. Check its status, linked conversation, and errors; scheduled runs also show the request ID. Decide who will review subsequent results and pause the schedule or trigger if problems occur.
Safety depends on workflow boundaries
“Please do not send anything” is an instruction, not a technical access restriction. Disable unnecessary write tools and review the permissions of connected systems. Treat email, documents, and webhook content as data, not trusted instructions: a request embedded in that content must not expand the original workflow. The human review point described here is an organisational process, not a blanket promise of a built-in approval gate for every tool.
Also plan for repeated events, outages, and stale sources. A webhook may arrive more than once; do not assume exactly-once processing. Filter or deduplicate events in the sending system or an upstream integration where needed. Start with a low frequency and clear ownership. Measure review effort, corrections, and errors rather than just the number of automatic runs.
Common questions about schedules and webhooks
- What is the difference between a schedule and a webhook?
- A schedule runs a saved question regularly at a chosen time and timezone. A webhook starts the agent after an authenticated JSON request from an external system and passes that data as context.
- Who can configure automatic runs?
- Creating and changing schedules and webhook triggers requires organisation admin access. Also decide who reviews the results and responds to errors.
- Does an automatically started agent also send email automatically?
- Built-in Outlook tools do not send email; they create drafts for human review and manual sending. Other tools need a separate review of their write and send capabilities. A schedule or webhook is not a general approval gate.
- Does a CRM or ticket webhook work without further setup?
- No. The source system must send an appropriate JSON request with the secret. Additional read access to CRM or ticket data requires approved tools. Automatically writing results back is not part of the webhook trigger.
Start with one workflow, one responsible person, and a result you can verify. A weekly report with read-only access is often a better starting point than an agent that changes data and sends messages at the same time. Extend the automation only when the initial runs can be reviewed reliably.
Prepare your first workflow