AgentScope 2.0.9: Agents Need Step Approval

Suppose the agent completes one step correctly 95% of the time.

In that case, a chain of 10 steps without checks will complete successfully in roughly 60% of cases (0.95 to the tenth power).

At 90% accuracy per step, 35% remains.

The figures are illustrative, but the mechanism is real: an error at the third step goes unnoticed until the tenth, producing a neatly formatted but incorrect result. An example from integration practice.

The agent matches a supplier price list with the PIM catalog, recalculates prices, and exports them to 1C.

If the agent confuses SKUs during matching, the export will still complete without technical errors, and customers will be the first to see the wrong prices.

Companies usually switch to a more powerful model in this situation.

Accuracy at each step increases by several percentage points, but an unchecked chain remains fragile: every additional stage multiplies the probability of failure again.

A milestone is a piece of work with a predefined completion criterion.

The agent completes a milestone, then code or a person reviews it through `/sop`, and only then does the next one start.

If the review fails, the agent repeats only that milestone; the run does not need to restart from the beginning.

Saved state addresses the second production problem.

If a service fails, a provider API times out, or an operator stops the process overnight, the run resumes from the last accepted milestone.

For a task that runs for hours and consumes tokens, this directly saves money.

Manual review through the API lets you add the responsible employee’s sign-off to procedures where errors are costly: changing prices, sending documents through EDI, or posting entries to an accounting system.

Engineers have long applied this logic in CI/CD: a build reaches production only after testing.

AgentScope developers brought this approach to agents.

The module is marked experimental, and its API may still change, so building critical production systems on it today is risky.

The principle can already be applied with any framework or your own orchestrator.

TeamPipeline speeds up tasks that can be divided into independent parts: reviewing a batch of contracts, checking product cards by category, and reconciling stock across warehouses. Parallelism comes at a cost: each participant uses their own tokens and adds another potential failure point.

If nobody reviews the participants’ results, the leader assembles the final outcome from unchecked pieces.

That is why we use SOP and TeamPipeline together: participants work in parallel within a milestone, and the result is reviewed at its boundary.

Three voice providers let you choose based on price, latency, and speech quality. CIS companies face an additional issue: a customer's voice in a call contains personal data, so lawyers must assess transferring such data to a foreign provider separately, before the pilot starts.

Four rules we apply in AI-native integration projects: 1. Procedure first, model second.

If an employee cannot list the process steps and the acceptance criteria for each one, an agent will not handle that process either. 2. Automated checks wherever possible.

Amount reconciliation, JSON Schema validation, and stock checks.

We involve a person where an error costs more than their time. 3. Saved state.

A long-running process must survive failures without losing completed work. 4. Models behind a gateway.

Our LLM & Security Gateway logs requests, masks personal data, and lets you switch providers (GigaChat, YandexGPT, Qwen, Claude) without rewriting the agent.

The agent accesses 1C, PIM, and CRM through MCP servers with restricted permissions.

Orchestration steps and events pass through Kafka or n8n, so every milestone is visible in the logs and can be restarted independently. From the outside, the setup looks simple.

For it to work, the team must establish data contracts, tests, and monitoring before the first demo.