I've been exploring a slightly different question while building an AI assistant

[Barman_Z (Barman-Zarei)]

I've been exploring a slightly different question while building an AI assistant:

Where should an AI assistant end and an agentic workflow begin?

I've been experimenting with these ideas through an open-source project called Brok.

The project explores how an assistant can combine natural interaction with practical tools and workflows, rather than treating the LLM conversation as the entire product.

I'm curious about how developers working with agent frameworks think about this boundary.

When does an assistant become genuinely useful as an agent, and when does adding more autonomy simply make the system harder to control?

Project: https://github.com/Barman-Zarei/Brok

I'd especially appreciate perspectives from people experimenting with agentic applications and tool-using AI systems.

[ILYA Khalafi (IlyaKhalafi)]

I’d draw the boundary around whether the system can stop and resume a task without repeating an effect. A conversational assistant can still use tools. More autonomy becomes useful when it can recover from interruptions while preserving the user’s intent and permissions.

There is a concrete test in Brok’s current loop. Cancellation is checked before and after each model turn, and the deadline before each turn. Neither is checked between calls in a tool batch. With the original loop and deterministic model/tool doubles, cancelling during tool one still executed tool two before returning cancelled. Advancing the test clock beyond the deadline during tool one likewise allowed tool two before returning timeout. Cancelling during the model response prevented both tools, as a control. No live model or desktop UI was tested.

Before adding more autonomous stages, I’d define that boundary explicitly. Check cancellation and deadlines before dispatching each new tool, and give a running tool its own cancellation or timeout handling where possible. Once tasks survive process restarts, record effect outcomes and reconcile uncertain ones before retrying.

For me, that is the useful progression from an assistant to a workflow. It can take more steps while giving the user a reliable way to stop, inspect and resume them.

[Barman_Z (Barman-Zarei)]

Thanks for taking the time to investigate Brok's loop and test these edge cases. This is exactly the kind of feedback I find valuable.

I agree that cancellation and deadline checks should happen before dispatching each tool, not just around model turns. Preventing unintended tool execution is important, especially as Brok evolves toward more reliable multi-step workflows.

I'll take a closer look at this behavior and consider adding deterministic regression tests for cancellation and timeout during tool execution.

I also like your point about recording effect outcomes before retrying tasks after interruptions. That's an important direction for making Brok more reliable.

If you have a minimal reproduction or test case for the current behavior, I'd be happy to review it. Thanks again for the thoughtful feedback!