Context
ChainWeaver captures runtime tool execution traces (#11) and proposes candidate flows from observed patterns (#12). contextweaver scores and routes tools based on static metadata. Currently, there is no feedback loop: contextweaver cannot learn from ChainWeaver's execution outcomes to improve future routing.
The weaver-spec architecture defines three layers (contextweaver → agent-kernel → ChainWeaver) with data flowing in both directions. The forward path is clear: contextweaver produces RoutingDecision, which informs execution. The return path — execution outcomes informing routing — is missing.
Why it matters
- Closes the learning loop — successful flow executions should boost the tools involved in future routing. Failed sequences should be negatively weighted. Without this, routing never improves from experience.
- Pillar 3 — "Create optimized aggregations and chains" requires learning which chains work. The traces are the signal.
- Ecosystem integration — this is the primary data channel from ChainWeaver back to contextweaver, making the two repos mutually reinforcing.
Proposal
TraceIngestor protocol + implementation
@runtime_checkable
class TraceIngestor(Protocol):
def ingest(self, trace: ExecutionTrace) -> None:
"""Process a completed execution trace to update routing heuristics."""
...
class ChainWeaverTraceIngestor:
"""Ingests ChainWeaver execution traces to update routing signals."""
def __init__(
self,
co_occurrence: CoOccurrenceTracker, # from #156
episodic_store: EpisodicStore | None = None,
) -> None: ...
def ingest(self, trace: ExecutionTrace) -> None:
"""
- Record tool co-occurrences from the trace
- Weight by outcome (success boosts, failure penalizes)
- Store as episodic memory for future routing context
"""
...
Trace format
The ExecutionTrace type should be compatible with ChainWeaver's ObservedTrace (#11) and ExecutionResult:
@dataclass
class ExecutionTrace:
trace_id: str
steps: list[TraceStep] # tool_name, success, duration_ms
overall_success: bool
source: str # "chainweaver", "manual", etc.
timestamp: datetime
Scoring integration
# In Router, after ingesting traces:
# Tools appearing in successful chains get a routing score boost
# Tools appearing in failed chains get a routing score penalty
# Boost/penalty is configurable and decays over time
Acceptance Criteria
Dependencies
Notes
- This is an optional integration module — contextweaver works without it. When ChainWeaver traces are available, routing gets smarter over time.
- The temporal decay prevents stale trace data from dominating: traces from 30 days ago matter less than traces from today.
- Consider a batch import mode for historical traces:
ingest_batch(traces: list[ExecutionTrace]) for bootstrapping from recorded sessions.
Context
ChainWeaver captures runtime tool execution traces (#11) and proposes candidate flows from observed patterns (#12). contextweaver scores and routes tools based on static metadata. Currently, there is no feedback loop: contextweaver cannot learn from ChainWeaver's execution outcomes to improve future routing.
The weaver-spec architecture defines three layers (contextweaver → agent-kernel → ChainWeaver) with data flowing in both directions. The forward path is clear: contextweaver produces
RoutingDecision, which informs execution. The return path — execution outcomes informing routing — is missing.Why it matters
Proposal
TraceIngestorprotocol + implementationTrace format
The
ExecutionTracetype should be compatible with ChainWeaver'sObservedTrace(#11) andExecutionResult:Scoring integration
Acceptance Criteria
TraceIngestorprotocol inprotocols.pyChainWeaverTraceIngestorimplementation insrc/contextweaver/adapters/orsrc/contextweaver/store/ExecutionTracedataclass compatible with ChainWeaver'sObservedTraceshapeto_dict()/from_dict()onExecutionTraceDependencies
CoOccurrenceTrackeras the primary storage backendingest_mcp_result()happy-path API for MCP artifact persistence #11 (trace capture) to have traces to ingestNotes
ingest_batch(traces: list[ExecutionTrace])for bootstrapping from recorded sessions.