Session-Start Notices

Email reaches a person who reads email; the portal reaches a person who opens the portal. Someone who works entirely through an agent does neither, and until they opened the portal they had no way to learn that a colleague had left a correction on an asset they own, or had shared a collection with them.

platform_info closes that gap. The first call of every session carries a notices block addressed to the person behind the agent, and the agent instructions in the same response tell the agent to relay it before starting on the request. It needs no configuration: wherever the portal and a database are present, every authenticated caller gets it.

What is in it

{
  "notices": {
    "since": "2026-08-10T09:00:00Z",
    "feedback": [
      {
        "thread_id": "thr_01HK7R8Z",
        "kind": "correction",
        "status": "open",
        "title": "wrong currency",
        "author_email": "[email protected]",
        "asset_id": "asset_01HK7R8Z",
        "asset_name": "Q3 revenue",
        "asset_reference": "mcp:asset:asset_01HK7R8Z",
        "last_activity_at": "2026-08-14T16:20:00Z"
      }
    ],
    "feedback_total": 3,
    "new_shares": [
      {
        "kind": "collection",
        "id": "col_01HK7R9B",
        "name": "Board pack",
        "reference": "mcp:collection:col_01HK7R9B",
        "shared_by": "[email protected]",
        "shared_at": "2026-08-15T11:02:00Z",
        "permission": "viewer"
      }
    ],
    "new_shares_truncated": false
  },
  "failing_automations": [
    {
      "name": "acme-dc-weather-watch",
      "display_name": "DC weather",
      "reference": "mcp:script:3f2a9c1e-0b7d-4f55-9a61-2d8e4b7c1a90",
      "version": 6,
      "run_id": "dpx_0de871f7ad2f350f7b63b8ffb8fe8edb",
      "cause": "upstream",
      "retryable": true,
      "error": "Error in fail: fail: NWS returned 500 for Phoenix",
      "consecutive_failures": 1,
      "failed_at": "2026-08-15T17:00:18Z",
      "last_succeeded_at": "2026-08-15T16:41:44Z",
      "scheduled": true,
      "new": true
    }
  ],
  "failing_automations_total": 1
}

feedback holds unresolved feedback threads on assets the caller owns. Threads the caller opened themselves, and replies the caller wrote, are excluded: your own comment on your own asset is not feedback awaiting you. The list is capped at ten; feedback_total is the whole count, so an agent says "three threads, here are the first two" rather than implying the list is complete. Each entry carries the asset's mcp:asset: reference, which fetch dereferences, and manage_feedback answers or resolves the thread.

new_shares holds assets, collections, and prompts granted to the caller by name, newest first. A public link nobody was named on is not a share with anyone and never appears. Each entry carries the reference that reads the artifact in full, and names the person who made the grant rather than the artifact's owner: an editor may share someone else's asset, and naming the owner would credit a person who did nothing. This list is capped at ten too, and new_shares_truncated marks a page that did not fit, so the count reads as a floor rather than as the whole set.

failing_automations holds the automations the caller owns whose latest finished run failed (#1934), newest failure first, capped at ten with failing_automations_total the whole count. It sits at the top level of the platform_info result, beside notices rather than inside it: releases up to v1.137.1 advertised notices as a closed object, and an MCP client still holding one of those tool lists refuses a result whose notices carries a key it does not declare (#1971). A failure followed by a successful run is resolved and not listed. An automation taken out of service is not listed either, however its last run ended (#1973): disabled by its owner (manage_script update with enabled false), or deprecated or superseded by an administrator. Enabling it again, or returning it to active, lists its failed run again. Each entry names the failed run (run_id, for manage_script get_run), the version it ran, why it failed (cause and retryable, the values the run itself records), the last line of its error, how many finished runs in a row have failed, when a run last succeeded, and whether a schedule will fire it again. Ownership is the automation's owner email, so an administrator is briefed on their own automations only.

Unlike the other two lists, this one is not bounded by the watermark: an automation that is still failing is listed at every session start, because being told does not fix it. new marks the entries whose failure arrived since the caller was last briefed, so a failure already relayed is not announced as new.

The feedback and share lists are a briefing rather than an inbox. The watermark advances past what did not fit, so what a capped list left out is not re-offered next session: the portal's activity feed and Shared With Me remain the complete views, and the agent instructions say so.

The notices block is absent when it has no feedback or shares to report, failing_automations is absent when nothing is failing, and both are absent for an anonymous caller.

Delivered once

since is the caller's notice watermark: the instant they were last briefed. Every feedback thread and share reported arrived after it, and delivering the digest advances it, so the next session is told only what is new since this one. That is why the agent instructions say to relay the notices rather than act on them silently — a notice the agent keeps to itself is not repeated.

Two details follow from that:

• A caller who has never been briefed has no watermark, and is briefed on the last 30 days rather than their whole history. Without a watermark the platform cannot tell what they have already seen in the portal, and announcing a two-year-old share as new would be false.
• If one half of the digest cannot be loaded, the watermark does not advance. A database hiccup delays a notice to the next session instead of swallowing it.

The watermark is stored per user in user_notice_watermarks, keyed by the caller's email address (or their user id when they have no email). It is deliberately not users.last_seen_at, which the directory refreshes asynchronously during the very session whose digest is being computed.

Relationship to the other surfaces

Surface	Reaches	Timing
Email notifications	People who read email	On the event, or in a daily digest
Portal activity feed	People who open the portal	Whenever they look
Session-start notices	People working through an agent	First call of a session

The three are independent: turning email off does not affect notices, and a notice relayed in a session does not mark anything read in the portal.

Ownership scope

Feedback notices cover assets the caller owns, resolved by user id, which is how the portal scopes every other owned-artifact view. Feedback on an asset merely shared with the caller belongs to its owner's briefing, not theirs; the portal activity feed is the cross-artifact view that spans everything the caller can see. A caller whose identity carries no user id owns no assets and so gets no feedback notices, though shares still resolve for them by email. A service account authenticating with an API key does have a user id, so an asset it saved is an asset it owns, and feedback on it reaches that principal's briefing.