Task Tracker Automation: Rules, Scripts or AI Agents

Task tracker automation is best built in three layers. Rules handle repetitive actions using an “event, condition, action” pattern. Scripts, scheduled jobs and the API connect the tracker to other systems and run logic that can’t be expressed as a rule. AI agents work with text: they summarize, classify and prepare drafts. Start with rules, move to the next layer only when the previous one can no longer cope, and keep agent actions that change deadlines or commitments under human confirmation.

This article is for IT managers, team leads and Plane and Jira administrators who want to remove manual routine from their tracker without getting an unpredictable system in return. We go through each layer, the tools in Plane and Jira, a “task → layer → example” table, risks and reliability principles.

Three layers of automation

Layer	What it does	Plane	Jira	Who maintains it
1. Rules	Reacts to an event based on a set condition	Automations	Jira Automation	Tracker administrator
2. Scripts and API	Logic across systems, schedules, complex calculations	Runner, API, Projects-as-Code	Scheduled Jira Automation, ScriptRunner, API	Developer
3. AI agents	Working with text and unstructured data	AI actions, AI agents, MCP connectors	Rovo	Process owner and developer

The layers don’t compete; they complement each other. A good automation setup usually consists of many simple rules, a few scripts and one or two carefully scoped AI scenarios.

Layer 1: rules

A rule is the cheapest and most reliable kind of automation. It’s configured in the tracker’s interface, it’s visible, and it’s easy to turn off.

What rules cover:

• Moving a task to “In review” when a merge request is opened and to “Done” when it’s merged. In Plane, this works through the GitHub and GitLab integrations.
• Assigning an owner by component or label.
• Notifying the person on duty in Slack when a top-priority task appears.
• Closing subtasks together with the parent task, or sending a reminder if the parent is closed but the subtasks aren’t.
• Labeling a task by the request source.

In Jira, this is handled by Jira Automation; in Plane, by Automations. This layer has one limitation: a rule knows nothing about context outside the tracker and handles multi-step logic poorly. When a rule starts growing a dozen conditions and branches, that’s a signal to move to the second layer.

A useful habit from day one is a consistent naming format. For example: “[Project] Event → action.” In six months there will be dozens of rules in the tracker, and the name alone should tell you what a rule does and where it fires. The second habit is testing a new rule in a separate sandbox project, not on the team’s working board.

Layer 2: scripts, schedules and API

The second layer is needed when automation has to run on a schedule, call external systems or perform calculations.

Typical scenarios:

• A weekly summary of overdue tasks for management.
• Creating a task in the tracker from a CRM deal at the “Contract signed” stage.
• Syncing statuses with the customer support system.
• Recalculating deadlines based on dependencies, or checking that a sprint has no unestimated tasks.
• Creating a standard set of projects, statuses and labels for a new client.

In Plane, scheduled actions use Runner, and standard structures use Projects-as-Code, where project configuration is described in code and deployed repeatably. In Jira, some of this is covered by scheduled Jira Automation and web requests, while complex logic has historically been written in ScriptRunner. Both trackers have an API for integrations that live in a separate service.

The price of the second layer is engineering discipline. A script needs an owner, a repository, logs and a clear response to errors. A script that lives on one developer’s laptop isn’t automation; it’s a risk.

Layer 3: AI agents

AI is useful where the input is text rather than fields: a bug description, a comment thread, a client email, meeting notes.

What already works reliably:

• Summarizing a long discussion in a task.
• Drafting a task description or a breakdown into subtasks.
• Classifying incoming requests by type and component.
• Finding similar tasks and possible duplicates.
• Answering natural-language questions about tasks and documentation.

What’s still best left to people: timeline estimates, priorities with consequences for clients, and autonomous bulk changes to tasks and permissions.

In Plane, AI comes in three layers. AI actions perform targeted operations on tasks and documents. AI agents, introduced in September 2026, work inside the workspace. MCP connectors and the agent for Cursor connect external AI tools to tracker data. In the cloud, AI consumes credits: 500 per seat per month on Pro and 1,000 on Business, according to Plane as of October 2026. In Jira, the AI layer is Rovo; check Atlassian’s current pricing for its terms.

We wrote more about which agent scenarios already pay off in AI agents in task management.

Choosing a layer: task → layer → example

Task	Layer	Example
Change status after merge	Rule	Merge request merged — task moves to “Ready for release”
Assign an owner	Rule	Label “payments” — owner from the payments team
Notify the person on duty	Rule	New P1 bug — message in the on-call channel
Weekly report	Script or Runner	Every Monday, a summary of overdue tasks for management
Task from the CRM	Script and API	Deal at the “Contract signed” stage — a project and launch tasks
Standard project structure	Projects-as-Code or script	New client — a project with statuses, labels and templates
Discussion summary	AI	Before planning, the agent prepares a digest for each task
Request classification	AI with confirmation	The agent suggests type and component, the person on duty accepts
Duplicate detection	AI	When a bug is created, the agent shows similar tasks
Changing deadlines and priorities	Human	AI can suggest; the decision stays with the owner

The selection rule is short: if a task can be described as a condition, it’s a rule. If it needs a schedule, an external system or a calculation, it’s a script. If the input is text and the result can be checked by eye, it’s AI.

Risks at each layer

Rules. Chains where one rule triggers another, and the task ends up bouncing between statuses. Rules that silently stop firing after a workflow change. Hundreds of undocumented rules that nobody dares to turn off.

Scripts. No owner and no logs. Access tokens with admin rights stored in code. A bug that makes a script change a thousand tasks overnight. Dependence on an API that changed when the tracker was updated.

AI agents. Confident but wrong answers. Overly broad permissions on the agent’s account. Sending task data to an external model without approval. Credit consumption nobody tracks. On managing agent access, see AI agent permissions: RBAC, MCP and delegation.

Kazakhstan context. Tasks often contain personal data: client names, phone numbers, WhatsApp conversations, attachments from the CRM. Some companies want this data stored in Kazakhstan. If the tracker is self-hosted on a server in Kazakhstan, automation should stay within the same environment: scripts run on your servers, and AI features either use a model inside the environment or receive only anonymized data. In Plane, AI is available in a self-hosted installation, and the Airgapped version runs entirely without internet using a local model. Any MCP connector or external AI service through which data leaves the perimeter should be agreed with the information security team.

Principles of reliable automation

The checklist we use to review any automation before launch:

1. Every rule and script has an owner and a one-line description of why it exists.
2. Automation runs under a separate account, not under an administrator’s personal account. The log shows that the action was taken by a bot.
3. Minimal permissions. The automation account can access only the projects and actions it needs.
4. Idempotency. Running it again doesn’t create duplicates or break data.
5. Limited blast radius. Bulk changes are first run on one project or in a report-only mode without writing.
6. Errors are visible. A script or rule failure goes to the team channel, not just to a log.
7. A human confirms anything that changes deadlines, permissions and commitments to clients.
8. Regular review. Once a quarter, the process owner goes through the list of rules and turns off the ones no longer needed.
9. AI cost tracking. Credits and model calls are tracked the same way as licenses.

Where to start: the first four weeks

Automation doesn’t need to be fully designed upfront. It’s more reliable to start from actual routine and add layers as needed.

Week	What we do	Result
1	Interview the team and review task history: which actions repeat, where tasks stall, who moves data between systems by hand	A list of 10–20 automation candidates with frequency estimates
2	Set up first-layer rules for the most frequent actions, create an automation account, document each rule	Working rules with owners
3	Take one integration or one report and build a script or scheduled job with logs and error notifications	The first second-layer automation in production
4	Launch one AI scenario in suggestion mode: summaries, classification or duplicate detection. A human accepts or rejects each suggestion	Data on how often AI suggestions are accepted without edits

What counts as a successful pilot. People have stopped doing by hand what the rules now do. No automation has changed data in a way that surprised the team. For the AI scenario, it’s clear whether its suggestions are accepted and whether its permissions should be expanded. If AI suggestions are rejected more often than accepted, it’s better to go back to rules and scripts than to expand the pilot.

Separately, record what is not automated. Decisions on client priorities, changes to access permissions and anything that affects contractual deadlines stay with people. It’s useful to keep this list next to the automation registry: it settles arguments when someone proposes to “hand this over to the agent.”

How we do it

We start with a diagnostic: we list the actions people repeat in the tracker and sort them into the three layers. Then we launch a pilot with one team: a set of rules, one or two scripts and, if it makes sense, one AI scenario under human confirmation. After a few weeks, we look at what has stuck, document it and scale to the other teams, handing over the guidelines and the automation list to the owners.

How the work is organized and what the result includes is described on our business automation page.

---

Sources. Plane pricing and AI credits: plane.so/pricing. Plane source code: github.com/makeplane/plane. Jira pricing: Atlassian pricing. Pricing data is as of October 2026 and may change.

Terms in plain words

Script

A small program a developer writes for what can't be configured as a rule: scheduled jobs, calls to other systems, calculations. It needs an owner, logs and tests.

Merge (merge request)

The moment when finished code changes are accepted into the main version of the product. On this event, the tracker can move the task to 'Done' on its own.

Workflow

The set of statuses and transitions a task moves through, for example 'In progress', 'In review', 'Done'. After it changes, old rules may silently stop firing.

Projects-as-Code

A Plane feature for describing a project's structure (statuses, labels, templates) in code and deploying it the same way every time, for example for each new client.

MCP connector

A connection based on the MCP (Model Context Protocol) standard through which external AI tools get access to tracker data. If data leaves the company perimeter, this is agreed with legal and the security team.

Idempotency

A property of an automation where running it again doesn't create duplicates or corrupt data. It matters because scripts and events sometimes fire twice.

Access token

A digital key a script uses to sign in to a system instead of a username and password. A token with admin rights stored right in the code is one of the main risks.

Sandbox

A separate test project where a new rule is checked before it's turned on for the team's working board.