Built-in automations

Tale includes ten automation packages: three mailbox syncs, three inbox digests, two GitHub review workflows, and GitHub and GlitchTip issue imports. Each starts as version 1 and Not deployed. The issue importers run manually; the other packages include schedules, which start switched off: after you deploy a version, the editor offers Turn on the trigger. Inspect their inputs, model, connections, and writes before an Owner, Admin, or Developer deploys a version.

Start with one package

Open Automations, select a package, and inspect its nodes in the workflow editor. Check that the required connector is connected. The packages name a model: when Tale adds them and none of your providers serves it, each llm node gets a comparable model they do serve, and the message of version 1 says which. A package added before any provider was connected — as every package of a new organization is — keeps its model, and validation warns about it when you save — choose a served model with Change model, which swaps it in every step at once. A test run uses mock responses; it validates the flow without proving access to your real mailbox or repository.

The packages are added when an organization is created. Existing versions are preserved when the shipped package changes; only its shipped name and description refresh. A deleted package stays deleted. Your edits create new versions, which you deploy separately.

Sync mail into the Inbox

These workflows pull new messages into conversations every five minutes. Each declares the Inbox view: deploying one adds that view to Home and offers its connected mailbox in the compose form. Before deployment, Home has no Inbox view. A link to the inbox shows a setup notice instead: for Owners, Admins, and Developers it points to Automations; everyone else is told that one of those roles must deploy an email automation.

A pass reads the mailbox's Inbox folder only. It tells the mailbox's own replies from a customer's by the mailbox address, which the first pass learns from the connected account and keeps on the connection as its From address; IMAP takes it from the login.

Connect the matching mailbox first. After the first live run, inspect its execution log and check that the expected messages appear in the Inbox view in Home.

Attachments are stored with their message, so you open and download them from the conversation. Gmail hands over each attachment only up to 3.5 MB: a larger one is still listed with its name and size, but you open it in Gmail.

Triage the Inbox

These workflows work on the Inbox that the sync automations fill, every six hours. Each one reads the open conversations of its mail connector whose newest message is the customer's and that no earlier pass has judged since that message arrived — 25 per run, or the limit you set, up to 100. The model decides for each thread whether a person has to reply, and how urgent it is.

What a run changes:

• The verdict is recorded on each thread, with its reason, so the next run looks at the thread again only when the customer writes again.
• The thread's priority is set to the model's verdict — but only when nobody has set one. A priority a person chose stays as it is.
• Where a reply is due, a second model call drafts one and leaves it on the thread as a Suggested reply: a card above the composer, apart from anything a person typed. Put in editor hands the text to the composer to edit and send; Discard drops it, and the thread is not proposed on again until the customer writes again. Nothing is sent by the automation. A thread that already carries a suggestion keeps it.

The run's output lists what was read, the model's summary, the threads that need a reply with their Inbox links, and the drafts it left. A run with nothing waiting makes no model call. Deploy the matching sync automation first; without synchronized conversations there is nothing to triage.

Import and synchronize issues

Import GitHub issues and Import GlitchTip issues use the same form to turn source issues into tasks. They start without a schedule. These imports read the source and write Tale tasks; they never comment on, close, or change the upstream issue and do not start an agent.

1. Connect the source under Settings > Connectors and choose its default credential. GitHub needs repository access with read permission for issues. GlitchTip needs its instance URL and a token with project:read and event:read; a project-provisioning token alone cannot read issues. Self-hosted instances must be allowed by the deployment's connector host policy.
2. Open the importer and choose Test run. Select the Tale project, then enter the GitHub owner and repository or the GlitchTip organization and project slugs. Optional labels or a GlitchTip search narrow new issue discovery. Maximum issues accepts 1–500, defaulting to 100.
3. Inspect the test result, deploy the version, and choose Run live with the same destination and filters. A test run uses fixtures and creates no tasks; only a live run verifies the real connection.
4. Open Runs and select the run. Imported tasks links to the corresponding Tale tasks. If another batch remains, Continue import carries the same source, destination, and continuation position into the next run. To import every issue on a schedule instead, an automation keeps that position between its occurrences: see Import every issue on a schedule.

Each synchronization discovers new issues and refreshes up to 500 linked issues, prioritizing the oldest checks. Linked issues are refreshed even when they no longer match the discovery filter. Run again to keep large collections current. GitHub pull requests are excluded. Repeating or retrying an import reuses the same source identity within a Tale project; repository and project renames update the canonical source link instead of creating a second task. Issues moved to another repository or source project remain linked and continue to refresh through earlier imports, provided the connection can read their new location.

A task's source card shows the latest source title, description and status separately. When it imports an issue, Tale cuts a title over 200 UTF-16 code units or a description over 20,000 (most emoji count as 2) to that length on the task, ending it in "…"; the source card and the linked issue keep the full text. Closing or resolving a source issue leaves the Tale task's status, title, description, assignee and priority unchanged. A source issue that becomes unavailable retains its last known snapshot; authentication and rate-limit errors fail the run rather than declaring the issue deleted. Review and complete work in Tale as usual.

Review GitHub work

Triage GitHub issues reads open issues, scores whether they are actionable and their priority, and returns a ranked shortlist with reasons. It does not write to GitHub or create project tasks. Its default limit is 50 issues per run.

Review GitHub pull requests reads open pull-request diffs and posts findings as review comments. Its default limit is 10 pull requests per run. It does not approve or merge a pull request. Review the target repository before running it live, because a repeat run can add another comment.

Both workflows require owner and repo. In Test run, supply Run input (JSON) using your repository’s values:

{
  "owner": "your-organization",
  "repo": "your-repository",
  "limit": 5
}

Before deploying, read the resolved input and output of the test run. For a live run, also check connector permissions and any approval requirements. Execution logs explains waiting, failure, and the recorded writes.