Loops

Overview

Loops let Pulse Agent handle repeatable work without waiting for someone to start a new conversation. A Loop can run on a schedule, react to a supported change in Pulse, or wait for you to start it manually.

Each Loop has written instructions, a trigger, an output, and an explicit set of permissions. It can read the Pulse records its owner can access and, when allowed, update the item that started the run or work across other permitted items. Optional capabilities add web search, memory from earlier runs, or access to selected MCP connectors.

Editing does not immediately change live automation. Pulse saves edits to a draft while the latest published version continues to run. Publishing creates an immutable version, so every run can be audited against the exact instructions and permissions it received.

Example loops

Loops are most useful when the work has a repeatable decision, a clear source of context, and a result that can be reviewed. For example:

• Every weekday morning, review high-priority issues that are still open and send a heartbeat with blockers, owners, and the next action.
• When an issue enters triage, check its description and comments, identify missing reproduction details, and leave a comment asking for the specific information that is missing.
• When a request is submitted, classify it from its content, add the appropriate fields, and notify the owner when it needs a human decision.
• Every Friday, review recent project updates and open questions, then send a concise summary of risks and follow-up work.

The following patterns show how trigger, instructions, and permissions work together.

Review incoming bug reports

Trigger the Loop when an issue is created in a triage team or when relevant fields such as status, priority, or labels change. Ask it to read the issue and its existing discussion, check whether the expected behavior, actual behavior, and reproduction steps are present, and comment only when information is missing.

Enable Read Pulse data for review. Enable Change Pulse data and permission to change the triggering item only if the Loop should comment or update fields. Repository investigation and coding sessions are not available to Loops in the current release, so instructions should not depend on them.

Create follow-up work after an incident

Use an issue event with conditions such as an incident label and a completed status. In the instructions, define what counts as unresolved follow-up work and how new issues should be titled, linked, and assigned.

This pattern requires permission to change other items, because the result is separate from the issue that triggered the run. Keep an action limit that prevents one incident from producing an unbounded number of issues.

Route new requests

Run when a request is submitted. The Loop can read the request, use its fields and description to determine the appropriate destination, and update the request when Pulse write access is enabled. Add conditions when only a subset of requests should be processed.

If the routing decision depends on an external system, connect only the MCP server that provides that context and narrow its available tools where possible.

Prepare a recurring project review

Use a weekly schedule and ask the Loop to review projects that match a clearly stated scope: for example, active projects owned by a particular team. Have it surface missing updates, overdue target dates, unresolved questions, and changes since the previous run. A heartbeat is a good output for this pattern because the Loop can stay quiet when there is nothing useful to report.

Create loops with Pulse Agent

Pulse Agent can turn a plain-language description into a Loop draft. A reliable way to start is to first describe the outcome, then refine the trigger and permissions in the editor.

1. Open Loops from the sidebar and select New loop.
2. Keep the current Personal scope and choose Agent as the starting point. You can also start blank and use Compose with Agent in the editor.
3. Describe the result you want, the records the Loop should consider, when it should run, and any actions it must avoid.
4. Review the proposed draft. Confirm the trigger, conditions, instructions, output, connectors, and permissions instead of relying on the prompt alone.
5. Select Review and publish, resolve any blockers, and publish the first version.

For example, instead of asking for “a weekly project summary,” specify the audience, selection rule, facts to include, output format, and boundaries:

Every Friday afternoon, review active projects owned by the Product team. Summarize changes from the latest updates, overdue target dates, and open questions. Send me a heartbeat only when a project needs attention. Do not change project fields or create issues.

Pulse Agent edits the draft; it never publishes on your behalf. You remain responsible for reviewing and publishing every version.

Create loops manually

You can configure a Loop directly when you already know its trigger and boundaries.

1. Open Loops and select New loop.
2. Create a Personal Loop. The scope cannot be changed after creation.
3. Choose a trigger:
   • Schedule for daily, weekday, selected-day, monthly, or hourly-interval runs.
   • Event for supported changes to an issue, request, project, initiative, or cycle.
   • Manual when the Loop should run only after you start it.
4. For an event trigger, choose the event and add conditions. When using an updated event, select the relevant fields that must actually change.
5. Write the outcome and instructions. Say what to inspect, what to produce or change, and what must remain untouched.
6. Optionally enable a Heartbeat output. Pulse Agent sends it only when there is something useful to report; notification delivery can be enabled separately.
7. Add MCP connectors only when the Loop needs an external source or action.
8. Review team access, write access, capabilities, and the action and duration limits.
9. Select Review and publish, then publish the version.

Scheduled runs use the timezone shown in the editor. Their time is approximate: Pulse starts the run inside the displayed window rather than promising an exact wall-clock second. Event conditions are evaluated after the change; all conditions in one group must match, while separate groups are alternatives.

Nothing runs until the first version is published. Publishing that first version also enables the Loop.

Update loops

Changes to a published Loop are saved as a draft and do not affect the version that is currently running.

1. Open Loops and select the Loop you want to change.
2. Select Edit.
3. Update the trigger, instructions, output, connectors, or permissions. The editor saves the draft automatically and shows its save state.
4. Select Review and publish to compare the draft with the live configuration and see every publish blocker at once.
5. Publish the draft. Runs accepted after publishing use the new version; runs already accepted keep the version they started with.

Disabling a Loop stops new automatic runs without deleting its draft, published versions, or run history. Re-enable it when you are ready for automatic triggers to resume.

Review a loop's runs

Every Loop keeps a run history so you can see when it ran, why it ran, and what happened.

1. Open Loops and select a Loop.
2. Select Run history.
3. Open a run to review its trigger context, the published version, instructions, outcome, effects, and recorded usage.
4. When a run reached Pulse Agent, open its conversation to inspect the complete execution context. Runs that were skipped before reaching the agent do not have a transcript.

The history distinguishes successful work, no-action outcomes, partial completion, failures, cancellations, and skipped occurrences. It also shows which actions were applied, denied, failed, or could not be confirmed. When a run fails, Pulse links the failure to the most relevant place to fix it, such as Loop permissions, capability settings, usage settings, or run limits.

You can also use Run now from the Loop menu. Event Loops ask you to choose a compatible issue, request, project, initiative, or cycle. Running a disabled or paused Loop this way is a one-off: it does not enable or resume automatic execution.

Restore a previous version

Published versions are kept as immutable snapshots. Restoring one does not immediately replace the live version; Pulse copies it into the draft so you can review it first.

1. Open the Loop and select Edit.
2. Open Published versions.
3. Select the version you want and choose Restore version.
4. Review the restored draft. Re-authorize or remove any connector or capability that is no longer available.
5. Publish the draft when it is ready to become the live version.

The version that was live before the restore continues to run until the restored draft is published.

MCP connectors

MCP connectors extend a Loop with context and actions from another service. Depending on the connected server, a Loop might retrieve documentation, read an error report, inspect a pull request, or post an update outside Pulse.

Connector access has two layers. Workspace policy decides which MCP servers may be used, and the Loop owner grants specific active connections to a Loop. The published version stores connection identifiers and optional tool restrictions—not copied credentials. If a connection is revoked, it stops resolving for the Loop.

Add and manage connectors

1. Open the Loop draft and find Connectors.
2. Select an existing connection, or connect an MCP server allowed by workspace policy.
3. Open the connector menu to narrow the tools the Loop may use.
4. Publish the draft to make the connector available to future runs.

Loop runs cannot use local bridge connectors that depend on your Mac being awake. Connectors must be reachable by the hosted runtime during unattended execution.

Pulse does not currently provide a dedicated shared Slack integration for Loops. If Slack is available to your workspace, it is used as an MCP connector under the connector's own authorization and tool limits.

Setup

Loops appear only in workspaces included in the current rollout. If Loops is missing from the sidebar, the workspace does not currently have the required feature flag or agent workflow capability.

Shared Loop management is not available yet. New Loops are personal, and their configuration, versions, results, and run history are private to the owner—even from workspace administrators. A personal Loop can still be granted access to permitted team data; that access does not make the Loop itself shared.

Workspace policy can allow or block individual capabilities and MCP servers. The editor shows unavailable capabilities with a reason and prevents publishing a draft that depends on access the deployment or workspace cannot provide.

Permissions

Permissions define the maximum scope of a run. They do not expand the owner's access: a Loop cannot read or change data its owner could not access directly. Grant the smallest set that can complete the job.

Team access

Team access controls which teams' data the Loop may read or change. A personal Loop can use all public teams or an explicit set of teams. Selecting teams limits the run's data scope; it does not share the Loop with those teams.

Pulse data access

Read Pulse data lets the Loop inspect permitted Pulse records such as issues, requests, projects, and documents. Change Pulse data lets it use available write tools, but the write-scope controls below still decide which records may be changed.

Remember previous runs lets the Loop use conclusions from earlier executions as context. Use it when continuity improves the result, and leave it off when each run should be independent.

Web access

Search the web lets a Loop query current public information and cite sources. It must be available in the deployment and enabled by workspace policy before it can be selected.

Web access may send parts of the Loop's context to external websites or search services. Do not enable it for work that may contain sensitive workspace data unless that transfer is acceptable for your organization.

Change the triggering item and other items

Write permission is split into two controls:

• Change the item that triggered it allows a run to comment on or update the issue or request that started it.
• Change other items allows changes beyond that item, within team access and the owner's own permissions.

The second permission is off by default. Enable it only when the outcome genuinely requires creating or updating related work. Scheduled Loops have no triggering item, so their write behavior is governed by team access, capabilities, and the permission to change other items.

Run limits

Every Loop has a maximum number of actions and a maximum duration. A run stops when either limit is reached and is recorded as partially completed. Use limits to bound cost and prevent broad instructions from producing more changes than intended.

Capabilities not available yet

Repository knowledge, coding sessions, and writing to externally synchronized issues are represented in the permission model but are not available to Loops in the current release. Pulse shows them as unavailable instead of accepting a setting that cannot execute.

Pulse also does not currently distinguish trusted external issue or request sources for Loop triggers, so there is no separate per-Loop external-source allowlist.

AI usage

Loop runs consume the workspace's AI allowance. Run detail records token usage, model, and duration when the provider reports them. If the allowance is exhausted, automatic runs pause instead of repeatedly failing. After an administrator resolves the usage limit, resume the Loop from its menu.

Pulse uses the workspace's existing AI usage and spend controls rather than a separate Loops credit balance.

FAQ

Related documentation

• Pulse Agent — how the agent works and where its permissions come from
• Issues — the issue lifecycle used by issue-event Loops
• Requests — request intake and routing
• Projects — project context for event and scheduled Loops
• MCP server — Pulse's MCP integration model