Cookbook: Agentic Orchestration From Issue to Pull Request

One of the questions I keep hearing now is simple:

Can we move from AI helping with snippets to AI helping run the full delivery loop?

For Business Central teams, I think the answer is yes, but only if the workflow is explicit. Not “ask the model and hope”. A real pipeline.

That is why this post is a cookbook. It is not a product pitch. It is a practical walkthrough of how an issue-to-PR workflow can be built for AL development, using a central orchestration repository pattern and GitHub Agentic Workflows.

Disclaimer: GitHub Agentic Workflows are still recent and in technical preview, and this specific setup should be treated as early-stage and not yet broadly battle-tested. In practice, the most reliable parts so far are issue triage, issue enrichment, and analysis workflows. Full end-to-end implementation is promising, but it still needs careful human supervision and should not be presented as a finished autonomous production system.

The Idea in One Sentence

Take a GitHub issue, triage it automatically, enrich it with source context, dispatch an implementation workflow, generate AL code and tests, compile it, and open a draft pull request in the target repo.

That is the pipeline.

Why This Matters

The interesting shift is not that the consultant disappears. The interesting shift is that the consultant becomes more of a supervisor.

Less time is spent repeating structure. More time is spent on:

• clarifying the problem
• validating the design
• reviewing the draft PR
• deciding what should actually be merged

That is the future I find most credible. Not full autonomy, but end-to-end development with stronger human supervision.

The Reference Pattern

If you want to study the architecture behind this approach, start here:

• GitHub Agentic Workflows technical preview
• gh-aw multi-repo reference

The reusable shape is simple:

• one central orchestration repository
• agent definitions in .github/.agents/
• human-readable workflow definitions in .github/workflows/*.md
• compiled workflow artifacts for Actions execution
• lightweight dispatcher workflows in target repositories

What the Workflow Actually Does

The pattern splits the pipeline into a few very clear stages.

1. Triage the issue

When an issue is opened, an issue-triage workflow reads the issue, looks for relevant AL source files, enriches the issue body, applies labels, and decides whether it is ready-to-implement.

That matters because raw issues are usually not implementation-ready. They need structure.

2. Dispatch implementation

Once an issue is labeled ready-to-implement, the dispatcher workflow triggers the feature-implementation workflow.

That workflow:

• reads the issue and comments
• checks project settings from app.json and AppSourceCop.json
• explores the target repository
• plans the change
• writes AL code and companion tests
• compiles until clean
• opens a draft PR in the target repository

This is the step where issue-to-PR stops being a slogan and becomes a real system.

3. Run quality gates on the PR

After the draft PR exists, the PR workflows take over.

The key ones are:

• al-code-review.md
• al-breaking-change.md
• al-perf-audit.md
• al-security-audit.md

Together they check naming, labels, permissions, public API changes, performance anti-patterns, and security concerns.

4. Keep the repo healthy after merge

The workflow does not stop at merge.

There are also follow-up automations for:

• permission set gaps
• translation gaps
• dependency upgrades
• changelog generation

That is important. End-to-end means more than code generation.

The Agent Structure

The agent hierarchy is intentionally simple:

al-development
└── bc-orchestrator
    ├── bc-researcher
    ├── bc-architect
    ├── bc-al-logic
    ├── bc-al-ui
    ├── bc-reviewer
    ├── bc-tester
    ├── bc-translator
    └── bc-cal-converter

That split matters because each agent does one job well.

• bc-researcher finds patterns and documentation
• bc-architect turns that into a plan
• bc-al-logic writes business logic
• bc-al-ui handles pages and reports
• bc-tester writes test codeunits
• bc-reviewer checks quality and compliance
• bc-orchestrator coordinates the phases

How To Build This Yourself

If you want to replicate the pattern for your own BC repos, the shortest path looks like this:

1. Create a central orchestration repository.
2. Store your reusable agent definitions in .github/.agents/.
3. Write your human-readable workflow definitions in .github/workflows/*.md.
4. Compile them with gh aw into .lock.yml files.
5. Add a token with cross-repo permissions for the agentic workflows.
6. Deploy a lightweight dispatcher workflow to each target BC repo.
7. Let issue triage decide what is ready to implement.
8. Open draft PRs, not final PRs, and keep a human in the loop.

The baseline commands are straightforward:

gh extension install github/gh-aw
gh aw compile .github/workflows/*.md

And the runtime model is project-agnostic:

• read app.json
• read AppSourceCop.json
• discover ID ranges and suffixes at runtime
• avoid hardcoding repo-specific AL assumptions

That is a big reason the pattern can travel.

The Human Role: Consultant to Supervisor

This is the part I think the community should pay attention to.

The future is not just faster coding. It is a different posture.

The consultant still matters, but the job shifts:

• from manually drafting everything
• to shaping the issue
• supervising the implementation path
• reviewing the draft PR
• deciding what quality means before merge

That is a better use of human judgment.

A Practical Warning

You should not copy this kind of pipeline and remove all review gates.

The useful version is the one that keeps the human checkpoints visible:

• issue clarification
• draft PR review
• security findings
• breaking-change decisions
• CI failures the agent cannot fix alone

That is what keeps the system productive without becoming reckless.

If You Want to Start Small

Do not build the whole machine on day one.

Start with this subset:

1. issue triage
2. implementation dispatch
3. draft PR creation
4. automated AL review

If that works, add dependency scans, translation sync, changelog generation, and wider org orchestration later.

That is usually the right order.

Why I Think This Matters for the BC Community

Business Central work has always had too much repeated structure. Too much time lost to setup, naming, validation, and cross-repo consistency.

Agentic orchestration is interesting because it can take that structure seriously. It can turn it into a repeatable pipeline.

And if the human remains the supervisor, that pipeline can help the community move faster without lowering the standard.