[FEATURE] Team/Enterprise: shared routines (org-owned scheduled agents)

Status Open
Reported on v2.1.109
Maintainer reply ✓ Yes — ashwin-ant
Activity 5 comments · opened Apr 15, 2026
💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Routines (scheduled remote agents) are currently tied to individual accounts. In a team setting, routines often serve the whole team (e.g., daily Slack summaries, automated PR checks). If the creator leaves the team, those routines become inaccessible breaking workflows the rest of the team depends on. There's no way to transfer or share ownership.

Proposed Solution

Allow routines to be optionally marked as "team-owned" so that:

  • Any team admin can view, edit, enable/disable, or delete them
  • They survive individual account removal
  • Ownership can be transferred between team members
  • They appear in a shared "Team Routines" section alongside personal ones

Alternative Solutions

  • Each team member recreates the same routine on their own account (duplicates effort and usage quota)
  • Move automation to GitHub Actions or external CI (loses the Claude Code integration benefits). Those integrations won't work without an API key.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

  1. I'm on a team account.
  2. I create a daily routine that reads #team-alerts Slack channel and posts a summary to #team-internal
  3. The whole team relies on this daily digest
  4. If I leave the org, the routine disappears and no one can recreate it without knowing the exact config
  5. With team-shared routines, an admin could take over or the routine would simply continue running under the org

Additional Context

This becomes increasingly important as teams scale and build more routines into their workflows. Similar to how GitHub Actions belong to a repo (not a user), routines that serve a team should optionally belong to the team.

Environment Info

  • Platform: linux
  • Terminal: konsole
  • Version: 2.1.109
  • Feedback ID: 6a72c8c4-8928-46c6-9574-e59065a0da4e

View original on GitHub ↗

4 Comments

ashwin-ant collaborator · 4 months ago

We're working on this!

yilixiang888-dot · 3 months ago

We solved this exact problem with a simple cron + file-system pattern. Sharing in case useful for the shared routines design.

Pattern: cron as scheduler, file-system as queue

1. Cron writes task files

# crontab - runs every hour
0 * * * * /bin/bash /path/to/cron-observe.sh
# cron-observe.sh
cd /path/to/project
python3 orchestrator.py alerts > /dev/null 2>&1
python3 orchestrator.py weather > /dev/null 2>&1
python3 orchestrator.py auto-evolve > /dev/null 2>&1

2. Persistent agents poll for tasks

Each agent is a long-running Python process that loops:

while True:
    for task_file in glob(".agent_tasks/{my_id}_*.json"):
        process(task_file)
    sleep(3)

3. Scheduled tasks can be one-shot or recurring

// .agent_tasks/sunbin_weekly_report.json
{
  "task_id": "weekly_report",
  "agent_id": "sunbin",
  "task": "Generate weekly sales report for 忆李香",
  "schedule": "0 9 * * 1",  // Every Monday 9am
  "recurring": true
}

Why this works well for teams/enterprise:

  • Zero infrastructure — no message queue, no server, just a shared filesystem (or git repo)
  • Auditable — every task and result is a JSON file, git log is your audit trail
  • Language-agnostic — cron writes bash, agents are Python, results consumed by anything
  • Survives everything — terminal close, machine reboot, network outage — tasks sit on disk until processed
  • Debuggable — stuck task? cat .agent_tasks/*.json. Failed task? .agent_results/ has the error.

Observation → Evolution pipeline

We added a feedback loop: every agent interaction is recorded as an "observation" in a JSONL file. When observations accumulate past a threshold (e.g., 20 new observations, 24h since last run), an auto-evolve job analyzes patterns and promotes high-confidence behaviors into persistent skills/rules.

This gives you autonomous improvement without any infrastructure beyond cron + files.

fmusayev · 3 months ago

+1. @ashwin-ant do you have an estimate for when this can be launched?

mark-savo · 1 month ago

+1. Concrete example: I set up a daily PR-triage routine that posts an open-PR status table (who owes what, plus QA/Prod branch freshness) to our team's #pull-request Slack channel twice a day. It's genuinely team infrastructure, but it's owned by my personal account — if I'm out or it breaks, no teammate can see, edit, pause, or take it over, and the Slack + GitHub connectors are all bound to me personally. An org-owned routine with shared visibility and edit rights would make this kind of team-facing automation actually maintainable.

Showing cached comments. Read the full discussion on GitHub ↗