Skip to content

feat: add Strands Agents runtime support - #52

Open
donatoaz wants to merge 1 commit into
patoles:mainfrom
donatoaz:feat/strands-runtime
Open

feat: add Strands Agents runtime support#52
donatoaz wants to merge 1 commit into
patoles:mainfrom
donatoaz:feat/strands-runtime

Conversation

@donatoaz

Copy link
Copy Markdown

Description

Adds support for Strands Agents as a runtime in Agent Flow, enabling visualization of Strands-based agent sessions alongside the existing Claude Code runtime.

  • Introduces strands-agentflow Python package with a HookProvider that emits JSONL events compatible with Agent Flow's event protocol
  • Adds a VS Code extension watcher (strands-session-watcher.ts) that monitors Strands session files and feeds events into the visualization
  • Adds a runtime launcher (strands-runtime.ts) for starting Strands sessions from the extension
  • Updates the relay script to support forwarding Strands events
  • Includes unit tests and a sample fixture for the session watcher

Test plan

  • Extension unit tests pass (32/32, including 4 StrandsSessionWatcher-specific tests)
  • Project-level tests pass (24/24, no regressions)
  • strands-agentflow Python package installs via uv and imports successfully
  • JSONL events are correctly emitted to ~/.strands/agent-flow/<session-id>.jsonl
  • Web app builds without errors (next build succeeds)
  • VS Code extension builds without errors

Adds native agent-flow support for AWS Strands Agents via a Python
HookProvider that emits AgentEvent JSONL and a TypeScript session watcher
that auto-discovers and tails those files.

- strands-agentflow: Python HookProvider package that plugs into any
  Strands Agent via hooks=[AgentFlowHookProvider()] and writes JSONL to
  ~/.strands/agent-flow/<session-id>.jsonl
- extension/src/strands-session-watcher.ts: session discovery + JSONL
  tailing (same pattern as Codex runtime)
- extension/src/strands-runtime.ts: runtime factory
- scripts/relay.ts: Strands watcher integration + fix SSE replay to send
  all sessions (enables tab-switching)
- Unit tests for StrandsSessionWatcher (4 test cases)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@cla-assistant

cla-assistant Bot commented May 14, 2026

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


donatoaz seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

@donatoaz

Copy link
Copy Markdown
Author

I also have a proposal to make supporting new runtimes more pluggable, this way the core stays unchanged and new runtime contributors adhere to an interace that keeps their contributions isolated and easier to test.. let me know if you are interested

@patoles

patoles commented Jul 11, 2026

Copy link
Copy Markdown
Owner

Hi @donatoaz, sorry for the long silence on this, and thanks for the patience. I went through the PR and I'd like to move it forward: it builds on the v0.8.0 runtime abstraction correctly and still merges cleanly.

A few things before I can merge:

  1. Could you sign the CLA? The bot link is above.
  2. web/lib/agent-types.ts still has runtime?: 'claude' | 'codex', so Strands agents won't get a runtime badge/logo in the UI. Adding 'strands' to that union (and a fallback in the places that pick the brand mark) would complete the loop.
  3. The session scan loop relies on the 10-minute ACTIVE_SESSION_AGE_S threshold to re-attach to stale sessions. Could you confirm the Strands watcher preserves that behavior (re-discovering a session whose file goes quiet and comes back)?
  4. Heads up that v0.8.1 added anonymous telemetry; if it's easy, tagging Strands sessions with their runtime there would keep the stats meaningful.

On the strands-agentflow Python package: I'm open to it, but I'd like to think about where it should live long term (this repo vs its own). Happy to discuss in the PR.

Also interested in your pluggable-runtime idea from the comments; if this PR lands first, that refactor would have three concrete runtimes to generalize from, which seems like the right order.

This was referenced Jul 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants