On this page
The first thing I want to know about an AI agent is what it is allowed to change.
A convincing answer is pleasant. A task moved to the wrong status is work for somebody else. Once an assistant can act inside a project, its interface needs to make that distinction very clear.
Bisonflow's Agent is entering beta as part of the 2.0 release review. It brings project questions, text and voice instructions, and reviewed issue commands into a workspace conversation. Beta is a useful word here. I want people to try real, bounded work and tell me where the result stops being dependable.
Begin with a question whose answer you know
A good first trial is a question about a project you understand. Ask what remains open for a milestone, or ask for an explanation of a task using the available project context.
Read the answer against the actual work. Did it find the right project? Does it distinguish a recorded fact from an inference? Can you follow the references? If something is missing, does it admit that, or write around the gap?
Knowing the answer in advance isn't cheating. It lets you evaluate the assistant before giving it a question you can't easily check.
I would avoid starting with "organize my entire workspace." That request conceals too many decisions about priority, ownership, and what counts as a duplicate. A narrow question gives both you and the product a fairer test.
Review the exact command
When the Agent proposes a supported issue change, the review should identify the target and the intended update. Read it as you would a small code review. Confirm that the selected issue is the one you meant and that the values match your instruction.
The approved command goes through the application's scoped server checks. Approval does not let it bypass workspace membership, project permissions, billing rules, or validation. The command also needs to avoid applying the same approved action twice when a request retries.
Those protections are part of the implementation. They don't mean every suggestion is correct. You can still approve an unhelpful edit, and the model can still misunderstand an ambiguous request. That is why the visible proposal matters.
For your first task update, use a task where an incorrect update is easy to notice and correct. Then inspect the task afterward. A successful chat response is weaker evidence than the state of the thing you asked it to change.
Voice should leave the same reviewable trail
You can use voice to supply an instruction, but the microphone doesn't create a different authority level. The result should be available in the conversation, where you can read it and inspect the proposed action.
This matters when speech is imprecise. Two tasks may share a similar title. You may correct a date halfway through a sentence. The system should use the finished instruction and clarify a remaining ambiguity rather than silently choosing a target.
I wrote more about that in the voice workflow article. The central test is whether speaking made useful work easier, including the review after capture.
The beta feedback I need
"It gave a strange answer" is a start. The useful report includes what you asked, which project you were in, what you expected, and what the Agent actually proposed or returned. If the error involved a task, identify it without copying private material into a public report.
Missing context matters too. An assistant that asks one focused clarification may be behaving better than one that answers immediately. Repeated questions about something already visible are a different problem. I want to find that boundary through use rather than assume a confident tone means we got it right.
Access and usage depend on the current workspace plan and configuration. The pricing page remains the reference for what you can buy today. The proposed future offer does not change those terms.
More autonomy is something to prove
I have no interest in celebrating how many tasks a model can create in a minute. A busy backlog is easy to manufacture.
I want to know whether you trusted the right change, rejected the wrong one, and understood what happened afterward. If that loop works, the Agent can take on more useful work. If it doesn't, giving it more tools would make the problem larger.
Start small, inspect the result, and keep the consequential calls yours. That is how I want this beta used.
