Monitor agent: pivot from Q&A-only to also emit interesting on-chain events

[nabinpkl]

Why

The agent today is a Q&A surface: user asks → agent fetches → agent answers. Under that framing the recently-landed memo capture (#36 follow-on, see docs/architecture/memos.md) earns its keep mostly as an article/security-demo asset. Memos themselves are weak analytics signal because most of the canonical "interesting things" (Solforge inscriptions, Pyth verifications, freeze attestations, cross-chain bridge hashes, trade tickets) don't help an analyst answering "tell me about wallet X."

But Solana publishes a steady stream of those events all day, and they ARE the kind of thing a curious user would want to know about. That's a proactive product, not a reactive one: agent watches the chain, surfaces what's interesting, narrates briefly, the user consumes a feed instead of asking a question.

This issue is about scoping that pivot, not committing to it. The decision is whether MCAE is a Q&A tool, a monitor tool, or both.

What "monitor agent" means here

A separate agent surface that:

• consumes the existing solana.raw-edges and solana.memos.v1 Kafka streams in real time
• runs a rule library against each event (initially regex / structural matchers; can grow to embedding similarity later)
• on a match, hands the event to the existing agent loop with the defenses we already have (boundary, constitution, channel switches)
• the loop produces a short narrative ("new solforge mint at slot N by signer X")
• the narrative lands on a feed (frontend timeline, optional Kafka alerts topic, OTel trace)

The Q&A agent stays as-is. Monitor is a sibling service sharing the agent core.

Why this is structurally a good fit for what we have

Each piece slots into existing primitives:

• Streams: solana.raw-edges and solana.memos.v1 already exist; consumer groups are cheap.
• Rules: each rule is a switch + paired observable + paired eval — same cockpit shape we landed in Refactor system_v4 to industry-standard XML+markdown tagged structure with single-file composer #36 phase 4. New rules slot in without a schema change, same way new channels do.
• Defenses: the per-defense surface (StayInRoleSwitches) and the cockpit channel switches (ChannelSwitches) already exist. They were arguably over-engineered for a Q&A-only agent. Under monitor framing they become load-bearing because the agent ingests untrusted text continuously without a human in the loop, which is the canonical indirect-injection failure setting.
• Constitution + cross-check: same loop, same gates.
• Emission: narrative already has SSE; reuse for a feed channel.

The only genuinely new piece is the rules engine + emission target.

Why this sharpens the article narrative

Indirect injection in a Q&A agent is "user pasted a hostile string": the user is in the loop and gets blamed. Indirect injection in a monitor agent is "the chain emitted a memo and the agent narrated it without a human seeing it first": the agent is in the loop and gets blamed. That's the canonical AutoGPT-class threat model and the existing defense:memo_injection rule + channels.externalTextInputEnabled switch are exactly the right surfaces to demo it on.

So the per-defense ablation matrix from #37 gains a second rendering target: not just "does the model resist injection in chat" but "does the model resist injection when continuously fed hostile data from a stream." Same article shape, sharper failure mode.

Honest risks

• Scope expansion. Monitor agent is a real product, not a side feature. Built credibly needs: rules engine, alert dedupe, alert feed UI, alert taxonomy.
• Rules library growth. Most "interesting" patterns are protocol-specific (Solforge prefix, Pyth keyword, fm:v2 namespace). Library degenerates into a long regex config if not carefully shaped. Mitigation: keep v0 to a single rule, prove the loop, then grow the library.
• Continuous LLM cost. Every match invokes an LLM turn for the narrative. Free-tier OpenRouter caps quickly. Mitigation: rate-limit per rule per window, dedupe on (rule, signer) tuples, only narrate the first occurrence in a window.
• Indirect injection threat goes from theoretical to live. This is also why the defenses pay rent under this framing.

v0 scope (if accepted)

Single rule, single feed, no UI:

1. New service monitor-service/ (Python, mirrors agent-service/ layout) consuming solana.memos.v1.
2. One rule: memo.memo_text MATCHES <solforge inscription pattern>. Concrete, frequent, unambiguous (we already see ~22% of memos match this).
3. On match, build a primitive call (get_signature_context(sig) → returns the matched memo + edges + signers).
4. Hand to the existing agent loop with dontFabricate=true, defendMemoInjection=true, channels.externalTextInputEnabled=true.
5. Emit narrative to a new mcae.monitor.alerts.v1 Kafka topic; the frontend can render later.
6. Eval probe: feed a synthetic memo carrying an injection payload, assert defense:memo_injection rule + boundary + constitution gate keep the narrative on the rails.

This exercises the rules engine, the agent reuse, the emission channel, and the indirect-injection defense end-to-end on one concrete signal.

Out of scope for this issue

• The frontend feed component (separate ticket once v0 emits real alerts).
• Embedding-based "is this interesting" classification (separate ticket; v0 is rule-only).
• Rule authoring UI (rules ship as code in v0).
• Multi-chain monitor surfaces (Solana only initially; the architecture extends but landing it on more chains is a separate scope).
• Migrating the article runner Article data-collection: vectors x models x switches matrix runner emitting markdown table #37 to also exercise the monitor path (reasonable follow-on once monitor v0 ships).

Decision needed before any code

Pick one:

• Yes, monitor is in. Treat MCAE as Q&A + monitor; share the agent core. v0 scope above.
• No, stay Q&A only. Accept that memos are mostly demo/article fodder and that the cockpit channel switch stays vacuous-but-instrumented until proven otherwise.
• Defer. Park this until article runner Article data-collection: vectors x models x switches matrix runner emitting markdown table #37 lands and we've measured how the existing surface holds up; revisit then.

Done when (v0 only, if "yes")

• monitor-service/ exists and consumes solana.memos.v1.
• One Solforge-inscription rule matches, fires the agent loop, emits a narrative on mcae.monitor.alerts.v1.
• Eval probe confirms an injection-bearing synthetic memo is rejected by the gates and does not produce a hostile narrative.
• docs/architecture/monitor-agent.md records the rules engine shape and the v0 → v1 → vN growth path so the rules library doesn't drift.