Discussion: smarter signal selection in get_context

[gregario]

Heya Pawel,

I'll clock off for the night after this. I've been looking through the get_context piece, thinking about how this could apply across my teams using our agentic workflows.

I've two thoughts: what context is returned and how we could expand that to capture transient learnings between sessions. I've expanded on the first below. Still mulling over the knowledge piece... a big part of our work right now is session handover across teams but I'm not sure yet what should sit in the protocol layer vs the repo. Anywho, re the get_context:

Currently, get_context currently returns the last 10 signals for an intent:

SELECT * FROM signals WHERE intent_id = $1 ORDER BY created_at DESC LIMIT 10

This is recency-based, not relevance-based. An agent starting work gets the 10 most recent signals regardless of whether they're actionable, resolved, or noise.

What would relevance-based look like?

An agent calling get_context is about to start work. What they actually need differs by signal type:

• blocked signals — only useful if the intent is still blocked. A blocked signal from last week on an intent that's now open is noise.
• conflict signals — only useful if the conflicting claims are still active. Resolved conflicts don't matter.
• request signals — inherently actionable, should always surface.
• completion signals — the most recent one per dependency is valuable context ("what just finished and what did they say"). Older completions less so.
• info signals — recent ones are useful, old ones fade in relevance. Last few as a catch-all.

So instead of LIMIT 10 it could be something like: all unresolved blocked/conflict/request signals, plus the most recent completion per dependency, plus last N info signals.

The signal types already carry enough semantic information to determine relevance... the query just needs to join against current state (is the intent still blocked? is the claim still active?) rather than using a flat recency cutoff. No schema changes would be needed... This is a smarter query in getContext that uses what's already there.

Wanted to discuss before writing code since it changes what get_context returns. Interested in your thoughts on the right heuristic.