Features

Agents

Agents are the workers of your workspace. Each one is a coding agent CLI (Claude Code, Codex, or OpenCode) that Modula spawns with a specific role, a prompt, and access to your workspace state. Agents do one piece of work per run, write their results back, and exit.

Agents never spawn each other. Instead, every change in your workspace (a task approved, a variant finished, a comment posted) emits an event, and Modula’s dispatcher spawns whichever agents have a matching rule. That’s what keeps tasks moving without you prompting each step.

The default team

Every new workspace comes with eight agents that implement the default pipeline:

Agent	Role	Writes code?
`jira-scan`	Mirrors Jira issues into your task list	No
`linear-scan`	Mirrors Linear issues into your task list	No
`github-scan`	Mirrors GitHub issues into your task list	No
`project-manager`	Sequences approved tasks onto the roadmap, works out dependencies	No
`researcher`	Investigates the codebase and writes a phased spec for each variant	No
`worker`	Implements one variant in its worktree, phase by phase	Yes
`code-reviewer`	Reviews a variant’s diff, posts findings, accepts or requests changes	No
`reviewer`	Judges all of a task’s variants together and gives the final verdict	No

They chain through events: approving a task wakes the Project Manager, its hand-off wakes the Researcher, each spec’d variant wakes a Worker, each finished variant wakes a Code-Reviewer, and so on through to the final Reviewer. You can edit any of them, or add your own. Defaults added in app updates appear in your existing workspaces automatically.

Tracker sync

The three scan agents mirror issues from your tracker into the task list. Each one needs two things:

The matching MCP server on its provider: the Jira preset for jira-scan, Linear for linear-scan, GitHub for github-scan.
Its scope, set in the Settings block at the top of the agent’s prompt: the Jira site and projects (or a JQL query), Linear teams, or GitHub repos to mirror.

Run a scan from the agent’s card, or add a cron schedule to keep tasks syncing on their own. Scans only mirror: synced tasks still wait for your approval, and fields you own in Modula (approval, variants, execution settings) are never overwritten by the next scan.

Ways an agent runs

Event rules. The agent fires whenever an event matches one of its rules. This is how the pipeline agents run.
Schedule. A cron expression with a timezone, for agents that should run on a cadence (a tracker scan, for example).
Manually. Agents marked manual get a Run button on their card. The scan agents ship manual-only; give them a schedule if you want continuous syncing.

The Agents page shows each agent as a card with a live status dot, its provider and model, its rules and schedule, and when it last ran.

Configuring an agent

Click an agent to edit it:

Provider and model. Which provider the agent runs on, and optionally a specific model from that provider’s catalog.
Rules. When the agent fires. Edit them in a visual builder (pick a field, an operator, and a value) or as raw expressions. Conditions in a row are ANDed; rows are ORed.
Schedule. An optional cron schedule with an on/off toggle.
Prompt. The agent’s full role prompt in markdown. This is where its behavior lives, so reshape it freely.
Context. The arguments the agent expects per run, like --task-id or --variant-id. The dispatcher fills these from the triggering event.
Skills. Reusable prompt modules. A core set (engine API, tasks, specs, workflows, worktrees) is always included; optional skills like AI Wiki can be toggled per agent.

Rules

A rule is a small expression evaluated against each event:


event.type == "variant.update" and event.data.status == "ready_for_review"

Rules can reference the event type and any field on the event payload, such as event.data.status, event.data.pipeline_status, event.data.approved, or event.data.author, combined with ==, !=, and, or, and parentheses. An agent fires if any one of its rules matches.

Looping

Some work benefits from repeated short passes rather than one long run. In a task’s Agent settings panel you can give an agent a loop amount for that task: the dispatcher then spawns it that many times in sequence, each iteration picking up where the last left off. The agent is told which iteration it’s on, makes incremental progress on non-final iterations, and finalizes (status changes, summaries) only on the last one. Looped runs show an iteration badge like i2/5 in the run list.

Runs, logs, and usage

The Agents page has two companion tabs:

Logs lists every agent run with its status, task, and variant. Open a run to watch its log stream live: the agent’s messages, every tool call it makes, and a final summary with duration and token counts. Running agents can be killed from here.
Usage tracks cost and token consumption per run, per agent, and for the whole workspace.

Logs are also plain files on disk under ~/.modula/<workspace>/logs/ if you prefer tail -f.