[FEATURE] Persistent observer agents with conversation access

Resolved 💬 3 comments Opened Apr 7, 2026 by slafollette-flosports Closed Apr 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Allow agent teams/profiles to run as passive observers of the main conversation, with the ability to interject when they detect issues — similar to a coworker overhearing you're about to do something risky or suboptimal and chiming in.

Motivation

Today, agent teams can only be launched for discrete tasks. There's no way to have a specialized agent passively monitor the conversation and offer advisory input based on its domain expertise.

Real-world parallel: a senior engineer sitting next to you who overhears you say "I'm going to SSH into the prod database to fix this" and asks "wait — are you sure that's the right call?" before you do it.

Proposed Solution

How It Could Work

  • Define observer agents via agent team profiles (existing concept)
  • Observers subscribe to the conversation stream (read-only access to messages and tool calls)
  • Observers can interject with advisory messages that appear inline in the conversation
  • User can configure which observers are active per session or globally
  • Observers have no tool access by default — they advise, they don't act

Alternative Solutions

Current Workarounds

  • Hooks: Can trigger shell commands on events, but can't reason about context
  • Periodic review agents: Can be launched at milestones, but miss real-time issues
  • Hook + CLI hybrid: A hook could shell out to claude with context, but it's fragile and high-latency

None of these replicate the passive, contextual awareness that a persistent observer would provide.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

Best practice enforcement — A code quality observer notices you're about to hand-write a wrapper for 68 API routes and suggests generating them programmatically instead.

Risk detection — A data integrity focused observer hears a plan to run a destructive operation and asks clarifying questions before it proceeds: "You're about to truncate a DynamoDB table in production — is
this the right environment? Have you confirmed the backup?"

Domain expertise — An architecture observer notices you're solving a caching problem and mentions that the codebase already has a CacheService pattern you should use instead of rolling your own.

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗