[GSOC 2026] Proposal for Idea #6 Interactive Progress Visualization & Task Stepping

[shreyakash24]

Hi maintainers,

Brief intro: I am Shreya and I’ve been doing open source and hacktoberfest(got the supercontributor badge as well)and I have been working on agentic AI systems where models orchestrate tool calls and multi-step execution chains. Because of that, the idea of exposing the agent’s runtime behavior in the CLI immediately feels interesting and familiar to me. I'm planning to apply for GSoC 2026 and I'm particularly interested in Idea 6 – Interactive Progress Visualization & Task Stepping.

While exploring the implementation, I sketched an approach based on exposing the agent runtime as a stream of execution events that the Ink UI could render incrementally.

Conceptually, the runtime could emit structured events such as:

• step_started
• model_response_received
• tool_call_started
• tool_call_finished
• step_completed

From these events the CLI could build a live execution tree, for example:

Task: Fix failing authentication test

1. search_code("auth.ts")
2. read_file("auth.ts")
3. edit_file("auth.ts")
4. run_tests → PASS

This would allow the Ink UI to update the visualization in real time as the agent progresses.

For the step-through mode, my initial thought is that the execution loop could pause right before a tool invocation and wait for explicit user confirmation, effectively allowing users to step through the agent's actions similar to a debugger.

Before finalizing the proposal, I had a few implementation questions:

1. Should the visualization expose full tool inputs/outputs, or would it be preferable to limit it to tool names + execution status from a UX or security standpoint?

2. If the model produces multiple tool calls in a single response, should those appear as sequential steps in the UI, or as children under the same planning step?

3. For step-through mode, would it make more sense to pause before every tool invocation, or only at higher-level agent steps to avoid excessive interaction?

4. For long-running tasks, should the execution trace persist after the command finishes (e.g., for post-run inspection), or should it only exist during the live session?

If this direction aligns with how the feature is envisioned, I’ll continue exploring the execution loop to identify the cleanest points where these trace events could be emitted.

Thanks!