Disclosure: I work on Tura.
A typical coding-agent loop calls the model again after each small step: inspect the repo, patch, build, test, then lint. That is 5 model turns for one ordinary change.
Tura exposes one macro tool, command_run. The agent sends a dependency-aware plan once; the runtime still runs the same checks, but without five separate model re-entries.
Example
normal: inspect -> patch -> build -> test -> lint = 5 LLM turns
Tura: one command_run plan -> same execution graph = 1 LLM turn
The ecommerce-ad-package run shows 5 turns vs 1 (80% fewer re-entries). It is not about skipping tests; it cuts conversational overhead around the same tool work.
- Benchmark run: https://turaai.net/benchmark-task?task=workflow-ecommerce-ad-package#runs
- GitHub: https://github.com/Tura-AI/tura
Where would this pattern help—or hurt—in your MCP agent workflow?
Top comments (1)
This pattern is attractive when the graph is known, but the important benchmark is not turns alone.
I’d compare task success, total input/output tokens, wall time, cost, retries, and unsafe or unnecessary side effects across the same tasks and seeds. A macro can save four model re-entries while also removing four opportunities to notice that the repository changed, a build exposed a new constraint, or an earlier assumption was wrong.
The plan should therefore be bound to an input snapshot/commit digest and revalidate preconditions before each node. Give every node typed capabilities, budgets, postconditions, retry policy, and cancellation semantics; a single macro tool should not become a single oversized authority grant.
On failure, return a structured partial-execution receipt: completed/skipped/failed nodes, exact commands and artifact digests, state changes, stdout/stderr references, and a resumable continuation handle. That lets the model adapt from the failed node without rerunning successful side effects.
I’d test it with mid-run repository changes, flaky tests, a patch that compiles but changes the required implementation, cancellation, timeout after a side effect, and parallel plan races. The best macro boundary is where execution is mechanical; semantic checkpoints should still be allowed to return control to the model.