[AlexanderZ-Band]

Why

#840 lets each turn carry room activity detail, but nothing reports it yet. Band's own tools (chat, contacts, memory, files and tasks) run through every adapter. Reporting them once, in the shared tool paths, gives every framework a visible tool_call with the tool's name before any adapter-specific mapping lands.

What

• runtime/toolactivity.py is the single owner of what a tool shows:
  • tool_detail maps a tool name to its activity. Memory saves (store, supersede, archive), taken from the registry, show memory. Every other tool, including memory reads, shows tool_call with its name.
  • tool_activity reports a tool's start and end on the turn that ran it.
    • It resolves the observer once, so a tool always ends on the turn it started on.
    • It reports only from the outermost call (a ContextVar). A Band tool that calls other Band tools shows as itself until it ends.
    • Reports are best-effort. A failed observer update is logged at warning and never changes the tool's result; cancellation passes through.
  • @reports_tool_activity wraps every agent tool method except send_event, which adapters also call to post their own events. A model's send_event reports at the dispatcher.
• activity_observer_of finds a tools object's observer with getattr_static. A duck-typed or mock tools object that never declared one runs unreported, instead of reporting to an auto-created attribute. DedupingAgentTools exposes its inner tools' observer.
• Band tools report from every shared entry point:
  • AgentTools execution
  • MCP dispatch_tool
  • the Pydantic AI, CrewAI and Parlant Band-tool wrappers
  • Strands' Band-tool bridge
  • the Slack tee, including its own slack_send_message
• Tests:
  • band.testing.ActivityRecorder (with observing(tools)) records what a turn observed. Producer tests assert through it.
  • One wire test runs a model band_send_message through a real ExecutionContext.
  • The new CrewAI and Parlant test files are listed in their lanes in ci.yml and in their coverage guards.

Scope

• Shared producers and Band tools only.
• Adapter-native tools, approvals and compaction come in the PRs stacked above. That includes custom tools on the MCP engine path (Claude SDK, OpenCode, Letta and the ACP client, all in the next PR) and Strands custom tools.
• Parallel tools resolve "latest wins".
• Second layer of INT-1744; stacked on feat: deliver compatible serialized activity detail #840.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DFmR3J53UqbsYDMmTUd3Rb

[linear-code]

INT-1744

[AlexanderZ-Band]

Blocking — would be REQUEST_CHANGES on a PR by someone else. Cycle 1 found three verified issues: housekeeping acquisition, cancellation cleanup during initial reporting, and a missing terminal-clear assertion. Public runtime/MCP/REST reproductions and the mutation check confirmed them.

[bandzalkin]

Scope

Reviewed #841 at a674b67f6deeea036f7f4a55bf9a34b5d7e935f2 against #840 at 06d8124481475460782840b8854285cf7c0a2d92, plus the complete #839 → #840 → #841 stack from a96fb54d0c9e496b22fb80353eea48656294b0cb. Scope includes provider mappings, approval waits, registered Band tools, and the changed validation toolkit.

Constraints

Activity must describe actual work independently of chat narration, remain bound to its originating turn, and carry semantic names rather than private arguments/results. Cleanup must preserve borrowed resources and active sibling work. Provider mappings must match released wire contracts.

Decisions

Keep the single scope-owned, serialized reporter. Correct observation identity and provider/toolkit boundary handling rather than add another reporting owner. R1 and R2 expose observation-lifetime gaps within that design; the overall direction remains appropriate.

Findings and proof

Five new P2 findings, R1–R5, inline. Each has an independently failing offline behavioral probe: real compiled LangGraph parallel execution; MCP dispatch across Claude wrapper rebinding; released Codex compaction events through the adapter; actual Agno callable dispatch; and real Phoenix subscription ownership against a local fake server. Details and smallest corrections are in the inline discussions.

The three earlier findings remain fixed and are not reopened: housekeeping acquisition, initial-report cancellation, and terminal-clear assertion. Their regression coverage passed. Narration gating and compatibility deadline/fallback attacks did not establish additional defects.

Executed on the combined stack using locked, isolated Python 3.12 environments:

Suite	Passed	Skipped
Core activity, tools, adapters, delivery and conformance (dev)	1,466	69
Coding adapters, ACP and turn admission (dev)	1,372	10
CrewAI activity (dev-crewai)	2	0
Parlant activity (dev-parlant)	3	0
Strands activity and CI-selection checks (dev-strands-nooa)	5	0

These passing suites do not cover the five failing scenarios. Live platform/model acceptance and the full repository gate were not run. No product files were changed.

Architectural / merge verdict

HELD — the stack is not merge-ready until R1–R5 are corrected and verified. Also resolve #839's current conflict with main before integration.

[AlexanderZ-Band]

Blocking — would be REQUEST_CHANGES on a PR by someone else.

Cycle 1 of /my-code-review: nested Band tools overwrite the outer tool's activity, Strands' model send_event is unreported, and observer failures break tool calls. Test gaps cover the Slack tee, CrewAI/Parlant send_event, double reporting, real Pydantic AI runs, family coverage and a realistic multi-tool turn. Four dropped claims are posted as resolved no-fix records.

[AlexanderZ-Band]

Cycle 2 of /my-code-review found no in-scope issues. There are two out-of-scope gaps:

• custom tools on the MCP engine and in Strands don't report activity;
• the Slack tee's own slack_send_message doesn't report.

The rest are nits and test suggestions. The five dropped claims are posted as resolved no-fix records.