Responsibilities

A responsibility is a specific automated task assigned to an agent. It defines what the agent should do, when it should do it, what tools it can use, and where to send the output.

Creating a responsibility

Creating a responsibility is a two-step process:

Step 1: Define the basics

Navigate to an agent’s page and click Create Responsibility.
Fill in:
- Name — A clear name for the task (e.g., “Weekly Deal Summary”, “New Email Triage”).
- Prompt — Instructions telling the agent what to do. Write this in natural language, as if explaining the task to a colleague.
- Trigger type — When the responsibility should run (see below).

Step 2: Review AI suggestions

After defining the basics, Alma suggests tools the agent should use for this task. Review and enable the ones you want, then create the responsibility.

Trigger types

Scheduled

The responsibility runs on a recurring schedule using a cron expression. Examples:

Every morning at 9 AM
Every Monday at the start of the week
Every hour during business hours

Scheduled responsibilities include timezone support. These are best for recurring tasks like weekly summaries, daily digests, or periodic check-ins.

Event-driven

The responsibility runs when a specific event occurs — a new email arriving, a Slack message being posted, a Linear issue being updated, etc. You can add filters to control which events trigger the responsibility.

Event-driven responsibilities are best for real-time reactions to incoming data.

Source event filters

Source event filters let you narrow exactly which events trigger a responsibility by matching against fields in the raw event payload. For example, you might only want a responsibility to fire when a Slack message is posted in a specific channel, or when a GitHub push targets the main branch.

When setting up an event-driven trigger, the event type dropdown shows only event types your org has actually received — so you’re choosing from real data, not a hardcoded list. Filter field suggestions are scoped to the selected event type and auto-discovered from your org’s actual event history. By default, 5 filter fields are shown; click + N more to expand the full list.

Filters are configured by workspace admins at Admin → Sources. When setting up an event-driven trigger, you can select any applicable filter from the trigger configuration panel. Alma shows a browsable JSON path tree from real sample events so admins can click to build precise filter expressions without guessing field names.

Matching events preview

The trigger detail panel includes a live preview of which recent events would match your current filter configuration. This helps you validate filters before enabling the responsibility:

A paginated list (5 per page) shows real events from your connected sources that match the active filters.
Click any field in the JSON tree to add it as a filter condition directly.
Filter value fields offer autocomplete suggestions drawn from your actual event history.

Use this preview to confirm your filters are targeting the right events before the responsibility goes live.

Manual

The responsibility only runs when you explicitly click Run Now. Useful for tasks you want to trigger on demand.

Running a responsibility manually

Any responsibility — regardless of trigger type — can be run on demand using the Run Now button in the responsibility header.

Run Now dialog

Clicking Run Now opens a dialog where you can:

Start the run — Alma immediately kicks off the execution and shows live status updates within the dialog.
Open in chat — Once the run is underway, you can jump directly into the chat sidebar to follow the agent’s progress in real time.

Replaying a past event (event-triggered responsibilities)

For event-driven responsibilities, the Run Now dialog lets you pick a recent source event to replay. Events are displayed in a human-readable list — each row shows:

An icon representing the source (Slack, Linear, Gmail, etc.)
A formatted title describing the event
The trigger type
How long ago the event occurred

Select an event and click Run to replay it through the responsibility with its original data. For advanced use cases, you can expand the Advanced section in the dialog footer to edit the raw event payload directly before running.

Configuring a responsibility

Navigate to a responsibility to see its details organized into three tabs. The View Tasks button in the responsibility header lets you jump directly to the agent tasks tab filtered to this responsibility.

Tasks tab

The Tasks tab is the default view. It opens with a summary header showing today’s outcome counts at a glance — how many tasks completed, failed, or were skipped. Below the header, an activity bar displays 24 hourly pills representing each hour of the day, giving you a quick visual of when the agent was most active.

The task list is divided into three sections:

In Progress — Executions that are currently running, shown in real time.
Failed — Executions that ended with an error, displayed in a two-column layout alongside In Progress so failures are immediately visible.
Complete — Finished executions grouped by date, with status-aware icons indicating whether each task completed successfully, was skipped, failed, or encountered an error.

Within the task list, the responsibility name is shown as the primary title for each item, with the execution’s generated session title on the second line.

Use the filters at the top of the Complete section to narrow by responsibility, outcome (completed / skipped / failed / error), unread status, or time range. The In Progress and Failed sections are unaffected by these filters. A search bar above the task list lets you filter completed tasks by keyword — type to match against session titles and responsibility names in real time.

Click any session to open it in the chat view. When viewing an active execution session, an execution progress sidebar is available alongside the chat. It shows each defined step of the responsibility — which steps have completed, which is currently running, and what’s pending — so you can follow the agent’s progress without reading through every message. If the pipeline has an acceptance gate, a final “Acceptance Criteria” phase appears at the bottom of the sidebar once the steps complete, indicating that human sign-off is required before the execution finishes.

Workflow tab

The Workflow tab contains all the configuration for how the responsibility runs, presented as a visual pipeline editor:

Trigger — Change the schedule, event type, or switch to manual. Scheduled triggers display the cron expression in human-readable form (e.g., “Every day at 9:00 AM”). For event-driven responsibilities, you can also select a source event filter to narrow which incoming events activate the responsibility.
Evaluation — Enable the evaluation toggle and provide an evaluation prompt to have Alma grade each execution. The evaluation prompt is required when evaluation mode is on. You can also configure the evaluation gate itself with a human approval requirement — select Any member or Specific users to require a team member to sign off before the evaluation result is accepted. AI evaluation and human approval are independent: a gate can be AI-only, human-only, or both. During evaluation, the agent has access to its accumulated memories from prior runs, so evaluation decisions can factor in context learned over time.
Steps — Each step is displayed as a card with two sections you interact with separately:
- Upper section (instructions) — Click to open the instructions dialog, where you set the step name and choose a step type:
  - Custom — Write instructions directly for the agent.
  - Skill — Reference an org skill to use its predefined instructions.
  - Event — Block execution until a specific source event matches your configured conditions. Event steps are evaluated deterministically against incoming events — no agent invocation, zero LLM cost. Configure pass/fail conditions using an event type and optional filters. While waiting, a pulsing “watching” indicator appears in the execution progress sidebar.
- Lower section (tools) — Click to open the tools dialog, where you enable or disable individual tools for this step and configure approval requirements.
For agent-invoked steps (Custom and Skill modes), tools are organized into two groups:
- Auto — Tools the agent uses without asking.
- Requires Approval — Tools that pause for a human sign-off before the agent proceeds.
Each approval gate shown between steps supports AI Approval (Alma evaluates automatically) or human approval (requires sign-off from any member or specific users). Gates support configurable retry attempts — if a gate is declined or times out and retries remain, approval is automatically re-requested without re-running the entire responsibility.

A save bar at the bottom of the Workflow tab lets you commit or discard any unsaved changes. The Run Now button in the responsibility header lets you trigger an execution on demand from here at any time.

Memory tab

The Memory tab shows memories accumulated by this responsibility across past executions — things Alma has learned from running this task. You can view, edit, or delete individual memory entries.

Managing triggers

Each trigger entry has two convenience actions:

Duplicate — Creates a copy of the trigger and opens it immediately for editing. Useful when you want similar triggers that differ only in one field (e.g., the same event type on a different source).
Reset — Reverts the trigger to its last saved state. The reset button is disabled when there are no unsaved changes.

Managing a responsibility

Renaming

To rename a responsibility, open its three-dot (⋯) menu and select Rename. A dialog lets you enter a new name without navigating away from the current view.

Moving to a different agent

To reassign a responsibility to another agent, open the header dropdown and select Move to agent…. Choose the target agent from the list and confirm. The responsibility — including its prompt, trigger, tools, and output channels — moves to the selected agent immediately.

Enabling and disabling

You can toggle a responsibility on or off without deleting it. A disabled responsibility won’t trigger on its schedule or events, but you can still run it manually.

Disabled responsibilities are sorted to the bottom of the sidebar list and visually faded so active responsibilities remain easy to find.

Testing

Use Run Now to execute a responsibility on demand and verify that your prompt and configuration produce the results you expect. For event-driven responsibilities, you can select a recent real event to replay rather than triggering on live incoming data — a convenient way to iterate on your setup without waiting for new events to arrive.

Visibility and members

Session visibility for a responsibility’s executions is governed by agent-level memberships. All members of an agent automatically have access to every execution session that agent runs — including past sessions. To give someone access to a responsibility’s sessions, add them as a member of the parent agent (see Agent settings → Members).

Session-level participation

Within an individual chat session, a watcher avatar stack appears in the chat header. Click it to open the participation popover, where you can add or remove people for that specific session only.

Unwatching

To stop following a session, open the session’s context menu in the chat sidebar and choose Unwatch.

Examples

Product Manager — Competitive Research

A Product Manager agent with a “Competitive Research” responsibility that keeps your team informed whenever competitors come up in conversation.

Trigger: Event-driven — fires when a competitor company is mentioned in a Slack channel.
Prompt: “When a competitor is mentioned in Slack, search our memory for everything we know about that company. Summarize what was said, any relevant context from past conversations, and post a brief to #competitive-intel.”
Tools: Slack (read channels), Memory search
Output channel: Slack message to #competitive-intel
Approval gate: None — the brief is informational, so it posts automatically.

Sales — Inbound Email Drafts

A Sales agent with an “Inbound Email Drafts” responsibility that helps your team respond faster to potential customers.

Trigger: Event-driven — fires when a new email arrives from someone who isn’t already a contact in your CRM.
Prompt: “When a new inbound email arrives from a potential customer, check our memory for any prior context on the person or their company. Draft a personalized reply that acknowledges their inquiry and suggests a next step.”
Tools: Gmail (read threads, draft emails), Memory search, Attio (lookup contacts)
Output channel: Draft email (sent back to the rep’s inbox for review)
Approval gate: Enabled on the email draft — the sales rep reviews and sends manually.