feat(workflow): silent agent-invocation action — wake an agent from a scheduled workflow without a visible channel post

[prabhatgmp]

Problem

There is no way for a scheduled workflow to invoke an agent to do work — i.e. no first-class "run agent" action, and no silent path to wake one. This blocks the natural "wake an agent on a cron to run a check/report" pattern.

Today the workflow action set is send_message / send_dm / set_channel_topic / add_reaction / call_webhook / request_approval / delay (crates/buzz-workflow/src/schema.rs, ActionDef). None of them says "invoke agent X with prompt P." The only way to wake an ACP agent from a scheduled workflow is to send_message a plain-text @mention — because p tags gate ACP wake (event_mentions_agent, crates/buzz-acp/src/lib.rs). That works, but has two rough edges:

1. It's not silent. The wake @mention is a visible channel post, so a daily "run this check" produces a visible nudge every day even when the agent then decides there's nothing to report. There's no quiet/DM channel for the wake.
2. send_dm — the one action that could make it quiet — isn't implemented (proposal Proposal: implement the send_dm workflow action (WF-07 TODO) #2628, "implement the send_dm workflow action (WF-07 TODO)").
3. The mention-wake path is also fragile for machine-generated text: workflow-emitted **@Name** (emphasis-wrapped) emits zero p tags and wakes nobody (workflow_sink's @-mention parser is a third divergent implementation — workflow-emitted **@Name** emits zero p tags #2686), so authors must hand-avoid markdown around the mention.

Concrete use case

A user asked an agent to "watch this GitHub issue and tell me daily only if something changed." The durable scheduler exists (workflow schedule trigger + cron loop, "fully implemented" per ARCHITECTURE.md), but there's no clean way to wire the daily fire to agent logic that decides whether to report. The workaround is a scheduled send_message that plain-text @mentions the agent — functional, but it posts a visible nudge every day regardless of outcome.

Proposed direction

A workflow action that invokes an agent with a prompt as a first-class step — e.g.

- id: run
  action: invoke_agent
  agent: "@Bumble"        # or agent pubkey
  prompt: "Run the #2699 watch; report only on change."

…delivered on the same channel that gates ACP wake (a p-tagged event) but without requiring a visible human-readable channel post — the invocation is a wake signal, not chat. If a full new action is too big a step, the minimal unlock is landing send_dm (#2628) so the wake can be a quiet DM rather than a channel post.

Non-goals

• Full agent-orchestration DSL / multi-agent choreography. This is just "fire → wake one agent quietly."

---

Surfaced while building a real daily-watch workflow (agent-side). Related: #2628 (send_dm TODO), #2686 (workflow mention parser drops p tags on emphasized names).

[makgunay]

The mention-wake path does not work today — measured, 50/50 failures

This issue's framing says:

The only way to wake an ACP agent from a scheduled workflow is to send_message a
plain-text @mention — because p tags gate ACP wake (event_mentions_agent). That
works, but has two rough edges…

It doesn't work. Not for emphasis-wrapped mentions (#2686), and not for plain-text ones
either. A correctly-emitted p tag on a workflow message wakes nobody, because the ACP
harness never reaches the mention filter for these events.

Root cause: the author gate runs before the mention filter

crates/buzz-acp/src/lib.rs:

:2154   let allowed = author_allowed(…)          ← runs FIRST
:2175   let matched = filter::match_event(…)     ← p-tag/mention matching

author_allowed → is_owner_or_sibling accepts only:

• author == my_owner, or
• an author whose kind:0 profile carries a NIP-OA auth tag naming the same owner.

Workflow output is signed by the relay keypair (crates/buzz-relay/src/workflow_sink.rs:254,
"Signed by relay keypair"), which is neither. Under RespondTo::OwnerOnly
(crates/buzz-acp/src/lib.rs:252) the event is dropped before match_event ever sees its
p tags.

It contradicts the relay's own stated intent

crates/buzz-relay/src/workflow_sink.rs:253-259:

//    - `p` tag attributes the message to the workflow owner
//    - one `p` tag per `@Name` that resolves to a channel member,
//      so mentioned agents are woken (wake is `p`-tag gated)

The relay believes wake is p-tag gated. The harness gates on author. Two crates, opposite
assumptions — and the sink's comment names event_mentions_agent explicitly, so the wake
path was read when this shipped; what was missed is that author_allowed runs before it.

Not a regression — a feature shipped into a pre-existing gate

	commit	date
author_allowed gate	dd9ce0902 (#1108)	2026-06-17
workflow mention-wake	64b8fea6d (#2034)	2026-07-17

The functional introduction of the author gate is dd9ce0902 (#1108); workflow mention wake
arrived a month later in 64b8fea6d (#2034). That ordering is likely why it shipped
unnoticed — the wake was written against a filter that a pre-existing gate already
short-circuits.

Evidence

Measured on a live deployment (relay crate 0.2.0; source read at 5457c947a74f5ba4b979f9c6411aa7626a858387):

• 4 workflow-emitted events carrying valid p tags to two live agents, in a channel where
  those agents are demonstrably woken by ordinary messages within ~1s. Zero wakes.
• Control: a plain agent-authored @mention in a brand-new channel → 👀 at +1s, 💬 at +2s.
  Provisioning and latency are not the cause.
• Both agents independently reproduced both halves.

Suggested fix

When an event is relay-signed and carries buzz:workflow, resolve the effective author
from the workflow's owner attribution before applying author_allowed, then let
match_event proceed normally. workflow_sink.rs:260-262 already sets a p tag to the
workflow owner for exactly this purpose — but it sits at index 0 with mention tags appended
after, so positional lookup would be fragile. An explicit buzz:workflow_owner tag would be
safer to resolve from.

This preserves owner-only semantics per-owner (your workflows wake your agents, nobody
else's) without allowlisting the shared relay key, which would grant every workflow on the
relay the same trust.

Bearing on this issue, and on the wider set

For #2702 specifically: the "rough edges" list is really one blocker plus one edge — wake
doesn't work at all right now, and **@Name** separately emits zero p tags (#2686). Both
sit on the same premise, so #2686's fix alone would not produce a wake either.

Possibly related, if maintainers want to triage these together: #2850 (forum-post mentions
never wake), #3105 (stream-channel mentions stored and visible but never traverse the
steer/wake path), #2462 (mentions in Projects comments never reach buzz-acp). We have not
verified those three ourselves — noting them only because "mentions don't wake agents" may
be a family rather than four independent bugs, and this one is the workflow-authored member.