Set up an Operations agent to manage Data records
Operations agents carry out repeatable data work on your behalf. You choose which collections they can access, what they are allowed to do, and when they run. Their output appears in your workspace for review before anything is published to customers. ## Before you begin - You must be a workspace owner or administrator. - The Data collections you want the agent to use must already exist in your workspace. - Decide whether the agent should create new records, update existing ones, or do both. ## Create an Operations agent New Operations agents use a **Guided setup** that takes you through four steps before creating the agent: 1. **Job** — give the agent a name, choose when it runs (manual, scheduled, or on a record event), write its instructions and choose a model. 2. **Sources & permissions** — add the collections, Sites and repositories the agent may use, and set the permissions for each. 3. **Schedule** — set the frequency and first-run time if you chose a scheduled trigger in step 1. 4. **Review and create** — confirm the agent's name, trigger, activation state and record permissions before Hub creates it. The setup retains your draft values if you navigate **Back** between steps or if creation fails. Access and configuration are rechecked before the agent is created. If anything is missing or invalid, Hub explains what needs to be fixed before you can continue. Existing agents continue to use the same editor tabs described below. The guided setup applies only when creating a new agent. ## Agent overview The **Agents** page now opens on an **Overview** tab that shows all agent families together — Service, Operations, Business specialists and the Executive Lead — with their purpose, source/target scope, enabled state, execution status and latest outcome. - Pending reviews, execution failures and business findings are kept distinct in the **Needs attention** section. - Use the **Family**, **Scope** and **State** filters to narrow the list. - Select any agent to open its editor. - Select **View run history** in the history filter to open the agent's run history pre-filtered. Workspace administrator access is required for the team overview. Members without administrator access can use the individual family tabs. ## Agent remit, constraints and owner Each Operations agent has a **Hub Compact workspace** that records its core mandate: - **Remit** — the agent's standing purpose and scope. - **Constraints** — any boundaries that limit what the agent should consider or act on. - **Owner** — the workspace member accountable for the agent's quality and configuration. These fields are separate from the agent's internal instructions. They give the broader team a clear view of what the agent is responsible for, and they are included in the agent's context when it runs. ## Assign goals as objectives You can assign specific Goals from **Goals & KPIs** to an Operations agent as formal objectives. For each assignment: - Choose the Goal the agent is responsible for. - Describe the agent's specific responsibility within that goal. - Set whether this is a **primary** or **supporting** contribution. - Choose a priority from 1 (highest) to 5. Assigned goals are included in the agent's run context so its work is explicitly grounded in the outcomes your team is tracking. ## Grant task creation permission Operations agents can create Hub tasks in a configured task collection. This is separate from general collection write permissions and must be enabled explicitly. 1. Open **Settings → Tasks → Agent permissions**. 2. Find the Operations agent you want to enable. 3. Turn on **Create tasks**. 4. Choose the **task collection** the agent may write to. 5. Optionally set a **default assignee**. 6. Save. When the agent creates a task, Hub validates the live permission, the agent's enabled state and the authorising admin. Request keys deduplicate retries. The agent may only create tasks in collections that are also listed under its **Sources & abilities** write permissions. To set the same task collection and default assignee for all your Operations, Business specialist and Executive Lead agents at once, use **Apply to all agents** in **Settings → Tasks → Agent permissions**. Individual overrides remain available per agent. Disabled agents stay disabled; future agents need their own grant. ## Agent settings tabs The Operations agent editor organises settings into five tabs: - **Identity** — agent name, colour and icon. - **Job** — trigger, model, written instructions, and task definition (for structured tasks). - **Sources & abilities** — which collections, Sites and repositories the agent can use. - **Schedule** — frequency and first-run time for scheduled agents. - **Test & activity** — preview runs and recent run history. A compact summary row beneath the tabs shows the agent's current targets, read sources and authority level. ## Structured task recipes Operations agents support a **structured task** mode with three built-in recipes: | Recipe | Abilities | Typical use | |---|---|---| | **Content writer** | Research, draft, review | Create articles, product copy or release notes from approved sources. | | **Record triage** | Classify, review | Route incoming records, extract key data, set status. | | **Record researcher** | Research, classify, review | Enrich existing records with researched information. | Recipes configure the task pipeline. They never grant collection or publication permissions — those must be added separately under **Sources & abilities**. In the **Job** tab, choose a recipe, describe the purpose, and map output fields to fields that exist in the target collection. Creates require a mapped Title / subject field. In **Sources & abilities**, choose target filters and explicitly grant Read, Create or Update permissions. Update outputs require a matching target selection. ## Preserve unsaved instructions during live updates If an agent's configuration changes in the background while you are editing its instructions, Hub reconciles the incoming update against your local edits. Fields you have changed locally are preserved; fields you have not touched are updated to reflect the remote change. Switching to a different agent resets the editing baseline. ## Grant collection permissions After choosing **Use configured capabilities**, a **What can this agent use?** section appears under **Sources & abilities**. Add only the collections this agent needs. For each collection you add, choose the permissions that match the agent's task: | Permission | What it allows | |---|---| | **Read records** | Read existing records to inform decisions or summaries. | | **Create records** | Save new records, unpublished by default unless publication is also enabled. | | **Update records** | Merge changes into existing records. Selecting Update automatically includes Read. | | **Archive / restore** | Archive or restore records. Selecting Archive automatically includes Update and Read. Archiving also unpublishes the record. | To enable creation or updates on published (live) records, select **Allow automatic publishing** at the bottom of the section. Leave this off to keep all agent output unpublished for human review. Note that updating a live record takes effect immediately under the permitted actions — there is no separate approval queue for updates. > **Permission dependencies:** Selecting **Update records** automatically grants **Read records**. Selecting **Archive / restore** automatically grants **Update records** and **Read records**. Revoking a prerequisite permission clears any dependent permissions that rely on it. ## Grant Site permissions Operations agents can prepare changes to selected Sites — such as pages, navigation, SEO settings, and selected shared blocks. To enable this: 1. Under **Sources & abilities**, add the Sites the agent should be allowed to modify. 2. For each Site, choose the permitted change types (pages, navigation, shared blocks). 3. Optionally enable **Automatic publication** for a Site to allow the agent to publish page changes without manual approval. Shared blocks always require human review regardless of this setting. Preparing a Site change does not alter the live Site. The run history shows a content preview and exact before/after fields, with **Apply** and **Dismiss** controls for each proposal. ## Grant code repository permissions Operations agents can submit scoped backend code changes as draft GitHub pull requests. This requires explicit setup: 1. Add a GitHub repository under **Sources & abilities**. 2. Define the editable paths the agent may modify. 3. Specify the named GitHub Actions checks that must pass before the change is considered verified. 4. The GitHub App installation must have **Contents** and **Pull requests** write permission, plus **Checks** read permission, before code work is enabled. Agents cannot run arbitrary shell commands, merge branches, force-push, or deploy. Required checks only pass when trusted GitHub Actions results succeed for the exact head commit. Removing a repository source also clears its code permissions, so reselecting it does not silently restore write access. ## Set a schedule (optional) If you choose **On a schedule** as the trigger, two additional fields appear under the **Schedule** tab: - **Frequency** — every 12 hours, 24 hours, 2 days or 1 week. - **First run** — the date and time for the first scheduled run, shown in your local time. Scheduled runs repeat from the first-run time at the chosen interval. The scheduler checks every five minutes and accepts runs within a 15-minute window. Missed slots are not backfilled. ## Run the agent To test or run the agent on demand: 1. Save the agent. 2. Select **Save and run now**. The agent will be queued immediately. Open the agent's **Test & activity** tab or the **Run history** to see the status change from **Queued** to **Running**, then to **Succeeded** or **Failed**. Each completed run shows: - A summary of what the agent did. - The proposal for structured tasks — change count, quality check result and approval actions, followed by reviewable record disclosures. - Links to any records it created or updated. - Site change proposals with Apply / Dismiss controls, where applicable. - Draft pull requests for code changes, including their CI check status. - Sources grouped by provenance — workspace records, GitHub pull requests, GitHub commits, GitHub files and repositories, or web sources. Each group shows five entries initially with a **Show all** control. - Duration and model usage. - Any errors. ## Structured task proposals and approval When a structured task runs, it produces a **proposal** rather than writing records immediately (unless the task's authority is set to **Apply permitted changes**): 1. The proposal shows the quality check result (**Passed** or **Needs attention**), a summary, findings, and individual record disclosures. 2. Review each proposed change — field values are shown exactly as they will be written. 3. Select **Apply reviewed changes** to commit the proposal, or **Dismiss** to discard it. Applying a proposal is atomic and version-checked. If the target records, collection schema or agent configuration changed after the proposal was created, the apply is rejected with a clear explanation of what changed. Run the agent again for a fresh proposal. A failed quality review cannot be applied — the **Apply** button is disabled until the quality check passes. If you try to apply changes to a published record without publication permission, Hub explains that no changes were applied and shows how to enable publication permission before running again. ## Task limits Structured tasks operate within these bounds, which are shown in the agent's settings: | Limit | Value | |---|---| | **Target records reviewed per run** | Up to 50 matching records | | **Proposed changes per run** | Up to 10 | | **Target collection scan ceiling** | 500 records | | **Reference records per collection** | Up to 30 | | **Evidence character limit** | 120,000 characters | | **Web searches per run** | Up to 5 (if research ability is enabled) | Collections larger than 500 records require a smaller source collection or narrower filters. Reference content is a sample — no completeness is claimed beyond the stated limits. ## Unified run history All agent families — Operations, Business specialists, the Executive Lead and Service evaluations — share a single **Run history** tab on the main Agents page. This replaces the separate per-agent feeds that previously appeared on each agent's own screen. - Select an agent from the dropdown to filter history to that agent only, or leave it set to **All agents** for a cross-agent view. - Expand any run entry to see its full output, site change proposals and code PR status on demand. - **View run history** links on each agent editor page open the unified history pre-filtered to that agent. Unified run history requires workspace administrator access. Service conversations remain in the Inbox and are not shown here. ## Search and filter run history The run history panel includes search and filter controls to help you find specific runs: - **Search** across run summaries, errors, record links, PR titles, and source titles. - **Filter by status** to show only succeeded, failed, or running entries. - **Filter by trigger source** to see manual runs, scheduled runs, or event-triggered runs separately. - **Needs review** filter surfaces runs that have unreviewed Data change proposals or Site change proposals. - **Load more** retrieves up to 100 recent runs, with a visible count of loaded results. Filters reset when you switch to a different agent. They operate only on the runs already loaded; they do not trigger a new run. ## Configure run notifications You can opt in to in-app notifications after an agent's run finishes. Notifications are off by default and delivery respects each recipient's personal automation-alert preferences. To configure notifications for an Operations agent: 1. Open the agent's editor page. 2. Select **Notifications** (visible after the agent is saved). 3. Choose **Notify when**: every completed run (including failures), or failures only. 4. Select the workspace users to notify. 5. Save the notification settings. You can also configure notifications for all agent families from the **Notifications** tab on the main Agents page. Select an agent from the dropdown, choose a mode, pick recipients, and save. Service agents support completed-evaluation notifications only (not a failures-only mode, since each evaluation is its own completion). ## Route agent alerts to Slack If your workspace has a connected Slack channel, you can route agent run alerts there in addition to — or instead of — in-app notifications. 1. Connect a Slack channel under **Settings → Integrations** (see *Connect Slack channels for agent alerts and automations*). 2. Open the agent's **Notifications** settings. 3. Under **Delivery**, select the connected Slack channel alongside or in place of in-app delivery. 4. Save the notification settings. Slack delivery uses an independent outbox with deduplication and bounded retry for rate limits and server failures. Delivery history is visible in the Notifications settings. ## Set up a configurable saved brief Operations agents can produce saved, dated reports — called **briefs** — on a schedule. Briefs replace the earlier fixed morning digest. To configure a brief: 1. Open the agent's editor and select the **Brief** tab. 2. Choose a **local calendar schedule** — weekdays, weekly or monthly — plus a timezone. Daylight saving adjustments are applied automatically. 3. Select the **reporting period** the brief should cover. 4. Choose the **collections, shared views or custom filters** that bound the agent's evidence. 5. Add or remove the **sections** the brief should include. 6. Set **recipients** and optional **Slack destinations**. 7. Save the brief settings. Saved briefs appear in the agent's run history with evidence references, query counts and explicit coverage limits. Generation uses read-only tools — the brief agent has no write access during a brief run. If you previously used a **legacy morning digest**, Hub provides an explicit, atomic conversion in **Workspace settings**. The conversion preserves your old enabled state, 08:00 UTC time, 24-hour period and personal notification preferences. You must select which collections the brief should use before completing the conversion. ## Notification drafts When you switch agents or close the notification editor before saving, Hub keeps your unsaved mode and recipient selections as a draft. A compact unsaved indicator reminds you to save before leaving the Notifications screen. Drafts are local to the browser session. ## Review the output New records created by the agent are unpublished unless you selected **Allow automatic publishing**. To review and publish them: 1. Open the collection the agent wrote to. 2. Filter for unpublished records. 3. Open each record and review the content. 4. Publish records that are accurate and ready for customers. 5. Edit or delete records that need improvement. Updates to existing records take effect as soon as the agent writes them, under the permissions you granted. Check the agent's run history to see exactly what changed. For Site change proposals, use the **Apply** and **Dismiss** controls in the run history entry. Stale proposals (where the target page has changed since the proposal was made) are rejected at apply time to prevent overwriting newer edits. For code PR proposals, open the linked pull request to review the diff and check CI results before merging. ## Troubleshooting **The agent fails immediately after saving.** Confirm the agent is enabled. The agent editor shows a toggle; the agent must be switched on before **Save and run now** will queue a run. **The agent reports a permission error.** Open **Sources & abilities** and check that the required permission checkboxes are ticked for the relevant collection. If you are updating published records, also check that **Allow automatic publishing** is selected. For Update permissions, remember that Read is included automatically. **Records are not appearing after a successful run.** The agent creates unpublished records by default. Open the collection, apply an unpublished filter, and check that records are present there before publishing them. **A run is stuck on Queued or Running.** Runs have a hard timeout. The scheduler marks any run that has been queued or running for more than 15 minutes as failed. You can run the agent again; records created in completed earlier runs are deduplicated and will not be created a second time. **The agent creates the same record twice.** If you supply source identifiers (such as GitHub pull-request IDs), Hub deduplicates records with the same source and collection. If no source is supplied, outputs are deduplicated within a single run but not across separate runs. **A Site change proposal is rejected when I apply it.** The target page may have been edited since the proposal was created. Open the page, review the current content, and ask the agent to re-run if an updated proposal is needed. **A structured task proposal is rejected when I apply it.** The proposal is atomic and version-checked. If the target records, collection schema or agent configuration changed after the proposal was prepared, the apply is rejected. Run the agent again so it prepares a fresh proposal against the current state. **Applying a proposal shows a publication permission error.** The proposal includes a change to a published record, but the agent does not have publication permission. Enable **Allow automatic publishing** in **Sources & abilities**, save the agent, then run it again to create a new proposal. **A code PR check shows as pending or failing.** Required GitHub Actions checks must succeed for the exact head commit before the change is considered verified. Confirm the workflow ran against the correct branch and that all required checks have completed. **The loading screen stays visible after an error.** Hub automatically retries loading after 15 seconds and immediately when a failure is detected. If the workspace or site fails to load, a reload option is also offered so you can recover without navigating away. **A Slack alert was not delivered.** Check the Notifications delivery history in the agent's Notifications settings. Slack delivery retries automatically for rate limits and temporary server failures. If the channel has been disconnected, reconnect it under **Settings → Integrations**.