When several AI models receive the same task without clear roles, work does not become faster. The problem moves into the handoff: no one owns the question, no one decides when answers conflict, and no review point is clear before the result moves on.
Fable Advisor is one open-source example of this design. Fable acts as the architect: it understands the request, decomposes the work and writes the specification. Other models implement the task, and Fable reviews the finished work in a clean context. This article explains the pattern and what it suggests for ERP, AI and software teams.
Separate the roles before you separate the work
Fable Advisor starts by deciding what each model is responsible for, before choosing which model to use.
- Architect owns requirements, decomposition, specifications and verification evidence.
- Producer implements the task through a lane matched to its complexity.
- Reviewer reads the result against the original goal and decides whether to ship, fix or rethink it.
This reduces the risk of one actor being the requirements writer, implementer and judge of its own work. Each role asks a different question: are we solving the right problem, how should the requirement be implemented, and is there enough evidence that the result is correct?
Route work by difficulty, not habit
Fable Advisor describes two main implementation lanes. Tasks whose specifications fully determine the outcome go to a Codex implementer using GPT-5.6 Luna. Work that requires judgment, such as concurrency, difficult debugging, security-sensitive changes or wide refactors, goes to a Sol implementer using GPT-5.6 Sol.
The point is not that one model is always best. The lane follows the work. Repeatable tasks can use a fast, consistent path. Risky work deserves more judgment and a higher reasoning budget. Setting effort per task is more useful than running every task at the maximum setting.
The same principle applies to business teams. A deterministic data transformation can be automated. Decisions about customer data, access rights or accounting rules need a named owner. Work that affects money or personal data needs a review point that someone can be held responsible for.
Manage token budget by task risk
Token budget is more than the final agent’s answer. Cost also comes from input context, repeated handoffs, tool calls and the review step at the end. Research on BAMAS treats budget as a constraint and selects both the model pool and collaboration topology before execution. Its experiments report cost reductions of up to 86% against the compared approaches, but that result is experimental evidence, not a promise for every system.
A practical workflow estimates the budget for planning, implementation and review, then records actual usage by task and handoff. Agents do not need equal quotas.
- Give well-defined work a fast lane and enough budget to finish in one pass.
- Reserve more budget for planning and review when the task is uncertain.
- If the task needs repeated retries, stop and inspect the prompt or input before adding more tokens.
- When context grows, pass only what the next step needs instead of forwarding the full history to every agent.
A handoff specification must answer the important questions
When the architect is not the implementer, the specification must carry enough context for another lane to begin without guessing. Fable Advisor’s contract covers the task, boundaries, constraints, completion criteria, escalation conditions and the reasoning effort appropriate to the work.
For ERP and AI work, a useful specification should state:
- what business step must change and what is out of scope;
- which system is the source, who owns it and which permissions must remain intact;
- what an observable successful result looks like;
- when the system must stop and ask a person;
- how the work will be tested and what evidence is required to call it complete.
This turns a handoff into a transfer of responsibility and acceptance criteria, rather than a long prompt passed to the next model.
Put review points before decisions, not after incidents
Fable Advisor uses commitment boundaries and a final advisor review. The reviewer reads the diff and evidence with fresh context instead of relying on the implementer’s confidence.
For Odoo or a business system, a review point might sit before code is merged, an accounting rule is changed, data access is opened to AI or a result is sent to a customer. The reviewer does not have to fix everything, but must decide whether the evidence is sufficient and where the work should stop.
Good review is not a layer of generic caution. It places a decision point where an error is still cheap to correct.
More agents do not win every task
The Mixture-of-Agents paper proposes layered agents, where each layer uses outputs from the layer before it. A later study with matched reasoning-token budgets found that single-agent systems matched or outperformed multi-agent systems on several multi-hop reasoning tasks.
These findings are not contradictory. Tasks that need multiple perspectives or cleanly separated subtasks may benefit from multiple agents. A task with a continuous context and a tight budget may be better served by one agent with more time to reason. Choose the architecture from measured quality, cost and latency instead of adding agents by default.
What to watch when models work together
Multiple models do not make a workflow correct by default. If the architect decomposes the wrong problem, a producer can execute it perfectly. If a reviewer sees the output without the acceptance criteria, polished work can still be approved even though it misses the actual need.
Access and data boundaries matter too. Each lane should know which records it may read and which information must not be sent to a model. Using AI with Odoo data therefore starts with permissions, source references and named approval points, not with opening every record and fixing the process later.
Turn the pattern into a team workflow
Choose one repeatable task, such as checking ERP readiness or drafting a product article, and write down the route:
- A person states the outcome and scope.
- The architect decomposes the work and sets acceptance criteria.
- The producer works through a lane matched to risk.
- The reviewer checks the result and evidence against the goal.
- An accountable person decides whether to ship, revise or stop.
This makes AI part of an operating process rather than a chat box whose answer everyone is expected to trust. The final decision still has an owner, conditions and a history that can be reviewed.
Fable Advisor is an open-source project by its author, not an Enersys product. This article does not claim that Enersys uses it in client projects. We are using its role separation, lane selection and cross-context review as a useful lesson for responsible ERP and AI workflow design.
Read the Fable Advisor repository and installation details
Talk to Enersys about ERP and AI workflow design
