An interactive story about coordination, context and human judgment in Business Central.

Prefer Spanish? Read the Spanish version on Substack.

When you are defining your agent stack, or more precisely your AI layer for coding, you have several primitives available to shape it. You need to be able to follow what they do, both individually and together.

That means experimenting and running tests. And, let’s be honest, auditing those experiments afterwards is rarely straightforward.

As I work on the evolution of ALDC, with the aim of making code generation more efficient, I am exploring a graph-based approach. Agents, other structures and participants act as nodes. We are a node too: ALDC-GRAPH, like ALDC, assigns validation decisions to us.

I am interested in the code it produces, but that only gives me a partial picture of the process. I want to know what each agent received and what it sent back: what travels along the graph’s edges. At this stage of ALDC-GRAPH’s development, understanding which dependencies shaped the work, and why someone decided to continue or change the plan, is perhaps the most important part.

I have put together a microsite to show that journey in ALDC-GRAPH. It draws on the records of an AL implementation for Business Central: a sales margin control extension covering thresholds, transaction blocking and exception authorization.

This was a sandbox run, with decisions made primarily to keep the process moving. The focus here is on how the system handles those decisions and their consequences, including when a human decision or validation may be mistaken.

The aim is to follow the process and understand its decisions without reconstructing the entire original conversation.

AL Conductor: a graph with review loops

AL Conductor is an orchestrator that leads a team of subagents. It coordinates the work and maintains the process state. The planning subagent analyzes scope and dependencies; the implementation subagent develops the agreed units; the review subagent examines the result and returns its findings. The Conductor uses those responses to organize the next step and request a human decision when needed.

I would describe it as a graph containing loops. The graph represents responsibilities and context exchanges. The loops allow an implementation to be revisited when a review calls for changes.

Connections are meaningful when they express a specific relationship: a task consuming another task’s output, a report returning to the coordinator, or an approval required before work can continue.

We design the context too

Context is essential. In more advanced agent setups, it extends beyond what agents know or what we tell them they need to know. Increasingly, we also need to identify what an agent does not know it does not know. That is the context we may need to supply or validate ourselves.

For example, in this run, authorizing an exception depended on both the sales line status and a previously defined contract for recording that exception. This relationship shaped the order of implementation.

In ALDC, context provides another element: checking technical decisions against concrete sources. The records include event signature checks against Business Central symbols and reviews supported by BCQuality. That gives us verifiable references against which to assess a proposal. Context also evolves as the process moves through the graph.

Decisions remain part of development

Human intervention had practical consequences. I admit that I did not spend long on many of these decisions: I wanted the agent workflow to continue, and I often followed the agent’s own recommendation. That was what I needed at this stage of testing.

During planning, I decided to group two independent specifications into the same implementation wave. The tests were written, but they were not run; accepting that as pending work was also my decision.

This is where I see the value of making the process visible. We can examine how work was distributed, what supported each decision, and what still needs checking. Corrections and changes of plan are part of engineering; their consequences need to remain reflected in the project’s records.

The artifacts ALDC-GRAPH generates also allow us to tell that story.

I clearly need more testing, particularly to avoid creating rules or workflows whose rigidity ends up stifling agility.

I encourage you to explore the interactive journey, and I would welcome your feedback.

Explore the interactive ALDC-GRAPH story, available in Spanish and English.

Learn about the main collection in the ALDC documentation and explore its public repository.

ALDC — AL Agentic Engineering System
Engineering systems, visibly reasoned.