Copilot Agent in AL: Using It Well Without Losing Control

In the previous post, I looked at Chat, Ask, and Edit and how each supports a different moment in AL development.

All three operate at a local level:

one file
one selection
one idea at a time

That makes them predictable once your intent is clear.

Copilot Agent works at a different level.

Instead of focusing on a single piece of code, Agent tries to complete a task — often across multiple files and objects. That difference is subtle in the UI, but significant in practice.

Used casually, Agent can feel unpredictable.
Used deliberately, it can be a powerful addition to an AL workflow.

What Copilot Agent Actually Is (In Practice)

Copilot Agent is often described as “autonomous”.
That description is partly true — but it can be misleading.

In practice, Agent is task-oriented.

Instead of answering a question or rewriting selected code, Agent:

interprets your input as a goal
decides which files or objects are involved
creates or modifies code to reach that goal

This usually means:

multiple AL objects
changes across files
decisions made on your behalf

Agent does not replace Chat or Edit.
It operates before them.

Understanding that shift in responsibility is essential.

A Typical AL Scenario Where Agent Makes Sense

Consider a common request:

“Add a Loyalty Program feature for customers.”

This immediately touches multiple areas:

a table extension for Customer
one or more page extensions
validation or calculation logic
possibly a setup table or codeunit

This is where Agent looks like the right tool — and sometimes, it is.

But the outcome depends on how you use it.

The key question is not:

Can Agent do this?

The real question is:

How much guidance does Agent need to do this well?

When Copilot Agent Helps Most

Copilot Agent works best when:

the scope is clear
the task is incremental
architectural intent is explicit

In AL projects, that often means:

Creating initial structure
Table extensions, page extensions, empty codeunits.
Expanding a feature step by step
One object or responsibility at a time.
Applying consistent changes across files
Renaming, aligning patterns, or extending existing structure.

In these situations, Agent acts as an accelerator, not a decision-maker.

It helps you move faster — provided you remain in control.

Using Agent Effectively Is a Process, Not a Prompt

The biggest improvement in Agent results comes from how it is used, not from finding a perfect prompt.

In my experience, Agent works best when treated as a collaborative process:

Start with a narrow task
Review the output
Refine the instruction
Add constraints
Continue incrementally

Instead of asking Agent to “build a feature”, I guide it step by step.

Typical constraints I include explicitly:

Follow AL design guidelines
Keep business logic out of pages
Apply common design patterns where appropriate
Respect SOLID principles
Avoid creating unnecessary objects

With this approach, Agent becomes far more predictable.
Not because it suddenly understands the domain, but because intent is reinforced continuously.

Where Agent Still Requires Caution

Agent becomes problematic when design decisions or business rules are left implicit.

Common issues include:

too many objects
inconsistent naming
logic placed in the wrong layer
a false sense of completeness

These problems are not unique to Agent — they simply become more visible because Agent operates across files.

Agent optimises for task completion.
Architectural correctness still depends on the developer.

Why This Is Especially Noticeable in AL

AL is a highly opinionated environment.

Patterns matter:

where validation lives
how extensions evolve
how responsibilities are separated

Copilot Agent does not know your architectural intent unless you make it explicit. Even then, small changes in wording can lead to different outcomes.

As a result, Agent can produce code that is:

technically valid
syntactically correct
but architecturally misaligned if intent is not reinforced

This is not a flaw — it is a limitation that needs to be understood.

A Practical Mental Model for Agent

A simple mental model helps keep expectations realistic:

Chat → think about a solution
Ask → understand existing code
Edit → improve selected code
Agent → implement structure incrementally

Agent is not a finisher.
It is a builder that works best under guidance.

How I Use Agent in Real AL Projects

In practice, I use Copilot Agent regularly — but deliberately.

I use it:

to scaffold new features
to add structure one step at a time
to implement decisions I have already made

I avoid using it:

for complex business rules
for final validation logic
when architectural choices are still unclear

In those moments, Chat, Ask, and Edit provide better control.

Why Agent Was Not Used in the Previous Post

In the previous article, I compared Chat, Ask, and Edit using the same small AL problem.

That comparison only works because:

the scope is limited
the problem is local
the intent remains stable

Agent operates at a different level.

Including it there would have blurred the lesson rather than clarified it. That is why Agent deserves its own discussion — and its own usage model.

The following screenshots show how you can typically work with Copilot Agent in a real AL project.
Each step is deliberate, constrained, and reviewed before moving on.

📸 Screenshot — Copilot Agent preparing a task

Copilot Agent preparing to execute a constrained, multi-step task.

📸 Screenshot — Incremental Agent output

Copilot Agent creating AL objects incrementally based on explicit guidance.

📸 Screenshot — Reviewing and refining Agent output

Reviewing Copilot Agent output before refining logic and structure manually.

📸 Screenshot — Refining Agent output with design constraints

Refining Copilot Agent output by explicitly reinforcing design principles and boundaries.

📸 Screenshot — Agent explaining design trade-offs

Using Copilot Agent to reflect on design choices rather than generate code.

Closing Thoughts

Copilot Agent is not a shortcut to finished solutions.

Used casually, it can create extra work.
Used deliberately, it can speed up implementation without sacrificing structure.

The difference is not the tool.
It is the intent you bring to it.

Once you treat Agent as a guided collaborator instead of an autonomous builder, it becomes a valuable part of AL development rather than a source of friction.

Copilot Agent works best when it is treated as a guided collaborator, not as an autonomous solution builder.

In AL development, structure and intent matter too much to be left implicit. Agent can help you implement decisions quickly, but it still needs clear boundaries, constraints, and review.

Used iteratively and deliberately, Agent becomes a useful accelerator. Used casually, it often creates more work than it saves.

In the next post, I will look at Copilot Plan mode, and how taking a moment to clarify intent before writing code can make both Agent and Edit far more predictable in AL projects.