Execution can adapt. The criteria for accepting the result should remain explicit.

We choose a model, ask it to solve a task and review what comes back. When it gets stuck, we switch models or seek a second opinion. That decision is part of developing with AI: how much effort to invest, when to keep trying and when to change approach.

HydraFusion brings that question into the runtime. For those of us working with AL and Business Central, it raises a practical possibility: could we delegate some model selection while retaining control over what counts as a valid solution?

That is the question I want to explore in relation to ALDC. The fit discussed here is conceptual; an integration test is still needed.

What HydraFusion proposes

GitHub offers HydraFusion as a research preview in Copilot CLI. It orchestrates models through three patterns: Single, direct execution; Cascade, drafting with escalation after a failed quality check; and Critique, review by a different model family followed by author revision. The critic is isolated, without tools or repository edits. Published results are offline evaluations, without AL-specific validation. GitHub recommends starting with bounded, single-prompt tasks. Source: GitHub.

What interests me is the possibility of matching effort to the task. A local correction and a decision with business implications may need different treatment. The practical question is whether the system recognises that difference and whether the result justifies the extra time and complexity.

It helps to distinguish a model, a role and a process. A model provides inference capability. A role defines a responsibility, such as implementation or review. A process establishes how those responsibilities relate and what conditions allow work to move forward. Switching models within a task does not itself change who must accept it, nor does it imply that several agents are working in parallel.

An AL task with clear boundaries

Consider a hypothetical example: implementing a validation that prevents an operation from being confirmed when required information is missing. Before running anything, we need to define the operation, when the check happens and what should happen when the condition is not met.

Suppose those decisions have already been made. The task includes the relevant code, required dependencies and acceptance criteria covering valid and invalid cases. That would be a sensible setting in which to explore adaptive execution: the work is bounded, and we can evaluate the result without renegotiating the requirement.

If we are still deciding what “confirm” means for the business, however, the problem remains open. A second opinion might expose the ambiguity, but someone with the authority to resolve it is still needed. More inference capability does not turn an unresolved decision into a specification.

In this example, correctness would also need to be demonstrated against the actual Business Central version and project. A persuasive explanation of the change cannot establish whether it compiles, runs at the right point or alters another behaviour that we needed to preserve.

Where it might fit within ALDC

ALDC, AL Agentic Engineering System, is the project through which I organise agent-assisted development around responsibilities, domain knowledge, artifacts and evidence. Whether considering its canonical approach or ALDC Graph, I want the relationship between requested, implemented and accepted work to remain clear.

One possible fit is within a bounded implementation task. The process would supply defined context and criteria; adaptive execution would attempt the task; the result would return to the process for validation. Turning that idea into an integration would require checking that the environment preserves instructions, supports the necessary tools and returns the expected artifacts.

In that design, acceptance of the task would remain with the process. Internal model selection could vary while the required outputs stayed explicit. That seems a useful boundary: it allows experimentation with execution without redesigning requirements whenever the underlying engine changes.

A second possibility does not depend on integrating HydraFusion. We could use the question it raises to examine our own orchestration decisions. Does every task need the same route? What signals would justify escalation? When would an additional review provide information we do not already have? Adopting that design principle would be ALDC's own evolution, distinct from incorporating the product.

The third option is to keep the current workflow. If a task already undergoes a specialist review, another review may repeat observations and add waiting time. Every intervention should have an identifiable purpose and an owner who can resolve disagreements.

What I would require before adopting it

The first check would be context continuity. Project constraints and acceptance criteria must remain available as execution changes. If a result misses a condition because that condition was no longer available during the work, the apparent saving loses its value.

The second would be separating opinion from evidence. A multimodel system's internal critic and ALDC's reviewer would have different mandates. I would not equate that critique with BCQuality either. A useful observation may prompt a check, but compilation or test results must come from the relevant tool and environment.

The third would be enough visibility to accept the work. I do not need every intermediate thought turned into a document. I do need to know what changed, what was checked and what remains unresolved. This proposal does not assume that internal traces can be exported or a model assigned to each role; both capabilities would need verification.

I would also measure the full cost. An execution that consumes less can still be more expensive if it requires more human correction. A slower one may be worthwhile if it delivers a correct change and reduces rework. The useful measure is the effort required to reach an acceptable result.

These boundaries would also make a failed experiment useful. We could identify whether the limitation came from missing context, an unsuitable task or an integration constraint, instead of treating every disappointing result as evidence that an entire approach does not work.

A small test before a larger decision

My conclusion is that there is a reasonable conceptual fit for bounded tasks, while the operational fit remains unproven. I would start by comparing the same AL task, with the same initial context and criteria, using the usual workflow and a variant with HydraFusion.

I would examine functional correctness, tests, total time, available cost data and human intervention, repeating the comparison to avoid deciding on the strength of one fortunate run. I would also record whether the additional review discovers different problems or merely repeats those already found.

If it improves verifiable results without making the work harder to understand and accept, there would be a reason to continue. If it duplicates reviews or shifts effort back to the person, keeping the existing workflow would be a sound engineering decision.

Javier Armesto · Open Engineering Notebook