Automations

Automations schedule agent work through the same task, provider, environment, and turn pipeline as interactive Tejus work. They remove the need to start every run manually; they do not remove the need to constrain, monitor, and review the result.

Where automations run

Automations run on your own computer, inside Tejus’s local server. The scheduler checks for due runs about once a minute while Tejus is open. Closing the Tejus window quits the app on Windows, so nothing runs while Tejus is closed.

When Tejus starts again after missing one or more scheduled times, the missed occurrences are by default coalesced into a single catch-up run, and the schedule then continues from the next future slot. Keep Tejus open (and the computer awake) when an automation must run at a specific time.

Good automation candidates

Automate work that is:

• Repeated on a predictable schedule
• Safe to run without a new design decision each time
• Easy to verify from its output
• Bounded to a known project and environment
• Useful even when one run fails cleanly

Examples:

• Summarize failing checks every morning
• Review newly opened issues on a schedule
• Re-run a known flaky reproduction until a stop condition is met
• Refresh a generated report from trusted inputs
• Check a repository for a specific maintenance condition

Avoid automating broad feature development, destructive cleanup, secret rotation, production deployment, or any workflow that requires human judgment at each run.

Create the automation

There are three ways to start one:

• Automations in the sidebar → New automation. Pick the project, write the title and prompt, then choose the schedule, run mode, and permissions.
• Type /automation followed by the task and schedule in the composer, or simply write a schedule-style request. Tejus turns it into an automation. If the task or schedule is missing it asks a follow-up question first, and when the interpretation is uncertain or the draft carries risk warnings it opens the draft for review before saving. Check the result on the automation’s page either way.
• An agent can propose an automation during a conversation. A proposal stays pending until you click Accept or Dismiss.

/automation Every weekday at 9:00, inspect open pull requests in this project.
Summarize failing checks and unresolved review threads.
Do not modify files or GitHub state.

Automations created from chat start with Approval required permissions; escalating to Full access is an explicit choice in the automation dialog’s Permissions menu.

Before relying on an automation, verify:

• Schedule (Repeats: Manual, Once, Hourly, Daily, Weekdays, Weekly, Custom, or Cron) and timezone
• Project and, for heartbeat runs, the target thread
• Provider and model
• Local checkout or worktree environment (Auto, Local, or Worktree)
• Approval required or Full access permissions
• Exact prompt
• Stop when condition, if any
• Whether the task may mutate files or remote systems
• The On failure policy

Do not accept a generated schedule merely because the natural-language interpretation looks plausible.

Choose a run mode

Heartbeat automations continue an existing task session and inherit its provider selection. Once a dedicated automation has started its thread, its provider is fixed; supported models and options can still change within that provider. Create another automation to use a different provider.

Agents that create or update automations through the Tejus agent tools (tejus_create_automation, tejus_update_automation) can name an exact provider and model for standalone and dedicated automations, using targets discovered from tejus_capabilities. When you explicitly ask an agent to create an automation, it can leave it disabled for review; inspect its saved model selection before enabling runs. A disabled automation is separate from a pending proposal.

Choose the environment

Scheduled writers should normally use an isolated environment. A recurring task on a shared checkout can collide with an interactive agent, manual edits, or another automation.

Write an automation-safe prompt

A scheduled prompt should state:

• What to inspect
• What may change
• What must never change
• How to verify the result
• What to report on failure
• When to stop repeating

Inspect the latest CI results for the default branch.

Allowed:
- Read repository and GitHub status
- Update the existing maintenance report file

Forbidden:
- Push commits
- Modify application source
- Close or merge pull requests

Verification:
- Validate the report format
- Include the exact check URLs and head SHA

Do not depend on hidden context from a previous interactive conversation. The durable prompt should carry the constraints needed for every run.

Stop conditions

Any automation can have a natural-language Stop when condition, whatever its run mode. After a successful run, Tejus evaluates the condition and disables the automation with a recorded reason when it is confidently met. Max iterations (Unlimited, or 10 to 250 runs) is a separate hard cap.

Use stop clauses for measurable completion:

• A test passes a defined number of consecutive runs
• A pull request reaches a specific state
• A migration report contains no remaining items
• A dependency version becomes available
• A known error stops appearing

Avoid subjective conditions such as “stop when the feature is good.” State an observable condition the run can demonstrate.

Run history and transcript labels

Automation-triggered turns are labelled in the task transcript, and each automation’s page lists Previous runs for triage. Notify controls whether you are notified about All runs or Failed runs only.

Review:

• Scheduled and actual run time
• Success, failure, or skipped state
• Provider and task used
• Output and reported verification
• File or Git changes
• Reason for automatic pause or completion

A successful scheduler dispatch does not mean the agent’s work was correct.

Choose a failure policy

The On failure policy controls how many consecutive failed runs Tejus tolerates before disabling the automation:

A successful run resets the consecutive-failure count. Duplicate reconciliation of the same run does not count as another failure.

When the threshold is reached, Tejus records the failure count and shows why it stopped (for example “Stopped after 3 consecutive failed runs”). Re-enabling is deliberate: inspect the failed runs, environment, provider state, and prompt before clicking Resume. Choosing Keep running does not automatically restart an automation that was already disabled by failures.

This policy is separate from Max iterations and the Stop when condition. Whichever stop boundary is reached first disables future runs with its own recorded reason.

Active and paused automations

The Automations list groups automations into Active and Paused. Use Pause / Resume and Run now on an automation’s page.

Pause an automation when:

• The repository is undergoing a conflicting migration
• Provider authentication or availability changed
• The prompt is producing ambiguous output
• The environment is no longer isolated
• Several consecutive runs fail without a new diagnosis
• A human decision is required before the next run

Resume only after reviewing the prompt, schedule, environment, and most recent failure.

Review scheduled changes

For an automation that edits files:

1. Inspect every changed and untracked file.
2. Confirm the run operated in the intended environment.
3. Review the exact diff against the correct base.
4. Run independent verification.
5. Commit or deliver only intentional changes.
6. Check whether the next scheduled run will repeat or conflict with the preserved work.

Do not allow unreviewed scheduled diffs to accumulate indefinitely.

Prevent duplicate effects

Repeated or retried runs can produce duplicate external effects when a prompt sends messages, creates issues, updates records, or triggers deployments.

Design for safe replay:

• Read current state before mutating it
• Use stable identifiers where the target system supports idempotency
• Record what was already processed
• Verify whether an ambiguous action committed before repeating it
• Keep external mutations narrow and explicit

A timeout is not proof that the action did not happen.

Failure handling

The run never starts

Check whether the automation is paused or a proposal is still pending, the schedule and timezone are correct, Tejus was open at the scheduled time, and the provider is installed and authenticated.

The run starts in the wrong repository state

Pause the automation. Inspect its task environment, base branch, worktree, and pending changes before another run.

The provider is unavailable

Do not silently substitute a different provider unless that fallback is part of the approved automation design. Pause, repair authentication, or make a deliberate provider change.

The stop condition fires too early

Disable the automation, inspect the recorded reason and evidence, then rewrite the condition to use a stricter observable signal.

Runs keep failing identically

Inspect the On failure threshold and the recorded disable reason. Do not merely re-enable the automation: require a new diagnosis rather than consuming repeated provider turns against the same broken assumption.

A run leaves an active process

Inspect the task terminal and stop dependent servers, watchers, or child processes before the next run or environment cleanup.

Automation checklist

• Schedule and timezone are verified
• Tejus will be open when the automation is due
• Project, task, provider, model, and environment are explicit
• Write authority is no broader than necessary
• The prompt states allowed and forbidden actions
• Verification is observable
• Stop conditions are measurable
• Consecutive-failure tolerance is explicit and appropriate for the action’s risk
• Repeated external effects are replay-safe
• Run history and task diffs are reviewed
• Failed or ambiguous automations are paused before retrying