FAQ

When developers start using agents in real Business Central projects, the same questions appear again and again.

These are the questions AL developers usually ask when they start using agents on real Business Central projects.

Access and Workspace Setup

I can't open the training portal.

Access to the portal is connected to the GitHub repo.

Send your GitHub username first. Then check your email and accept the GitHub invitation. Only after that your account becomes a collaborator on the workshop repo, and only then the portal opens.

One important thing to remember: use the same GitHub account when you sign in to the portal. If you send one username and sign in with another, access will not work.

Do I write AGENTS.md by hand?

Of course no.

Tell the agent that you follow spec-driven development. Then describe how you want this process to work in your project. The agent writes AGENTS.md for you.

Same for rules or skills. You do not need to become a markdown engineer. You describe the behaviour. The agent converts it into a reusable rule or skill.

How do I share skills and rules across every project?

I recommend one template repo.

Put the SDD setup there: skills, rules, and AGENTS.md. Then connect this repo to each project as a git submodule, the same way we connect the Business Central source code.

Think of it as your team "guidelines" for agentic development.

If a skill improves during a real project, ask the agent to create a pull request back to the template repo. Review it before it lands. A skill changes how all developers work, so treat it like a coding guideline.

The demos are in Cursor. I'm in VS Code, and the snippets don't paste.

Ask the agent to adapt the snippet for VS Code.

That is the simplest answer. Don't spend twenty minutes trying to manually fix the issues. This is exactly the kind of repetitive work the agent should do.

The .cursor folder is mostly a historical thing. Before AGENTS.md, each agent looked into its own folder. Now AGENTS.md can point the agent to the actual folder with your skills and rules.

In simple words: the folder name matters less than what AGENTS.md tells the agent to read.

The agent keeps asking me to Allow a PowerShell script. Do I click Allow all?

Well, no.

First read what the agent wants to run. Then allow that specific tool.

An agent works through tools. Reading a file usually does not ask for confirmation. Running a script usually does, even if the script only reads something. A fresh VS Code setup can be very strict here.

That is your harness protecting you.

Allow known read tools. Keep confirmation for anything that writes files, deletes files, publishes apps, or runs scripts you have not reviewed yet.

Steering the Agent

My colleague and I used the same cheat sheet and got different apps. Do we delete it and run again?

No. Continue the conversation.

LLMs are probability models. The same prompt, the same model, and the same setup can still produce different output. With agents this is even more visible, because one small difference in one tool call can change the next step.

The cheat sheet gives direction. It should lead the agent to Items instead of Resources, or Blanket Sales Orders instead of a custom subscription engine. But field names and small implementation details can drift.

Missing three fields? Tell the agent to add these three fields. Rebuilding from scratch can lose the parts that were already correct.

The agent told me to go back to the customer. The field isn't in the technical design.

This is a good warning.

You asked the agent to build something that is not in the design. The agent is not blocking you. It is telling you that scope changed.

If this change is intentional, say it clearly: "This is a deliberate addition. Add the fields and continue." Then decide whether specs/tech-design.md should be updated.

Remember - the agent can help you keep the project honest. It should not silently smuggle new scope into the code.

Do I rewrite the feature spec after the code diverges?

I usually don't.

The feature spec is the history of what you asked for. It is okay if implementation gives you a slightly different result.

What should be updated is the high-level technical design. specs/tech-design.md should describe how the app works now. Do it during the replan step, after the feature is done and before you start the next one.

If the design becomes too long, ask the agent to compact it and reference the feature spec. The design should explain the system, not duplicate every feature file.

The implementation is so big I don't understand my own code.

Then the feature is too big.

A good feature is something you can review. Not in three hours. In about fifteen minutes. It should have clear input, clear output, and tests that prove it works.

Now, you might think: "But the customer asked for one pricing feature." Right?

Not really. A pricing engine with interfaces, setup, posting logic, and tests is not one feature for an agentic workflow. It is several features grouped under one business topic.

How do I know when to give the agent a broad task, and when to guide it line by line?

Look at whether the agent has an example to follow.

If the same kind of implementation exists in the base app, System Application, recent BCApps code, or your own company app, a broad task can work well. Ask the agent to find that example first and follow the same pattern.

If there is no example, the situation changes. The agent starts to guess. This is where you need to be the guide.

In simple words: broad prompt when there is a pattern. Hand-holding when there is no pattern.

Why can I see an AL warning, but the agent cannot fix it?

Because you and the agent may not see the same signal.

A small compiler warning is a good example. If there is an extra semicolon before else, and the agent cannot find it after a few attempts, point to the exact line.

It is not "stupid." It may simply not see the same warning you see.

In Cursor, AL MCP and the AL extension Problems window are two different places. The warning can be visible to you in the editor, but not visible to the agent through its tools.

Rules, Context, and Sub-Agents

It shipped without tooltips, without suffixes, with logic dumped in OnValidate. When do I add a rule?

After the feature works.

During implementation the model is focused on what to build. If your coding standard is not in the current context, it will invent its own. This is exactly why Think Like an LLM matters.

The pattern is simple:

1. Build the feature. Get it compiling and tested.
2. Run a quality pass. Ask the agent to check tooltips, suffixes, OnValidate logic, and BCQuality rules.
3. Create a rule. When the correction is right, ask the agent to remember it.

Notice the order. You do not need to interrupt the implementation loop every time the first draft is not perfect.

Isn't it faster if I just edit the bad code myself?

For one line, yes.

For the project, no.

If you silently fix the code, the agent learns nothing. Next feature, it can repeat the same mistake. If you ask the agent to fix it and then save the pattern as a rule, you improve the workflow.

In simple words: do not only fix the code. Fix the process.

What is a sub-agent actually for?

A sub-agent is for focused work that should not pollute the main chat.

Tooltips. Documentation review. Warning cleanup. BCQuality pass. These tasks need context, but they do not need to stay in the main feature conversation forever.

The sub-agent spends tokens, of course. But it does not fill your main context window with low-level investigation.

Think of it as a small temporary worker. It does the task, returns the summary, and disappears.

I tried a big AL orchestrator pack. It burns credits and over-engineers. Should I stay on it?

I would start with the simple loop from this workshop.

Spec. Implement. Test. Docs. Finalise.

Some orchestration frameworks add a conductor, many sub-agents, and gates for every decision. It looks safe. But let's be honest - if every small step becomes a multi-agent ceremony, your token usage explodes.

Add sub-agents where they help. Do not build a committee for every tooltip.

Testing the Work

Do you test by hand?

The agent runs the tests. You review them.

In my production workflow, the agent writes tests first. The spec gives acceptance criteria. The agent writes tests, publishes with AL MCP, runs them, and sees them fail. That failure is expected.

Then it implements the feature and repeats the loop until tests pass.

But when the agent says "done", I don't start by clicking around inside the Business Central. I open the tests first. Do they test the real requirement? Do they follow the base app testing patterns? Are they meaningful?

If the tests are good and green, then I review the app code.

The test script demands a Docker container. I only have a sandbox.

That script is from the time before AL MCP could publish and run tests.

It used BcContainerHelper, so it needed a Docker container. Today AL MCP can publish and run tests against a SaaS sandbox. Ask the agent to use AL MCP for this workflow.

Keep an eye on one thing: make sure the app is rebuilt before it is published. Early AL MCP versions sometimes tested an old .app file. If the result does not match the code you see, tell the agent: rebuild, publish, run tests.

UI tests are still special. al_run_tests cannot reliably drive a TestPage. The AL MCP page explains when the container test runner is still useful.

New tests never showed up, so the agent hid them inside an old test codeunit.

That is a workaround, not a solution.

The test code was probably fine. The publish or test discovery step was stale. The agent could not see the new tests, so it tried to put them somewhere it knew was already discovered.

Stop the loop and fix the workflow:

1. Rebuild the app.
2. Publish the new package.
3. Run the new tests.
4. Do not move tests into old codeunits just to make discovery work.

Then update the skill, so the next run starts with the correct sequence.

How do I test an integration without calling the live system?

Mock the payload.

A test codeunit that depends on Customer Engagement, or any external API, is fragile. It can fail because the network is slow, because data changed, or because the other system is down. That is not a hard test of your AL logic.

Test the data shape. Test how your code reacts. Test mapping, validation, and error handling.

The BC MCP is for an agent that needs to read or write a live company. It is not your test runner. If you build your tests around live round trips, your test suite becomes slow and unstable.

Tools and Harnesses

What do I actually gain by using Cursor instead of VS Code?

Right now, mostly cost and workflow preference.

Cursor started earlier with agentic development UX. VS Code caught up a lot. The core workflow stays the same: SDD, skills, AGENTS.md, and the right MCP tools.

I use Cursor for AL work because I like reviewing generated blocks before they land. But this is not about one IDE. The process matters more than the logo.

Cursor or Claude Code?

For AL code that will go to production, I prefer Cursor.

Why? Because it is still an editor first. I can review generated blocks, accept some, reject others, and keep close control over the diff.

For personal projects or experiments, Claude Code is also fine. Same SDD setup. Same idea. Less manual review on the way.

One practical detail: Cursor does not use your Claude subscription. It has its own subscription.

Our legacy app has more than a thousand warnings. The agent drowns.

Focus it on errors first.

A syntax error is concrete. A thousand warnings from a C/AL migration are noise. If the agent sees all of them at once, it can spend the whole session reasoning about things that do not matter for the current feature.

If your tool allows it, hide warnings until errors are fixed. Then run a separate warning pass with a sub-agent.

In simple words: warnings are a separate task. Do not mix them into the implementation loop unless you really want the agent to work on warnings.

Opening the workspace hangs while it loads the submodules.

The AL extension tries to analyse everything in the workspace, including the Business Central source code you mounted for the agent.

You cannot exclude the submodule from that analysis in a clean way.

Set "al.backgroundCodeAnalysis": false in your settings.json to disable background analysis. Analysis still runs when you build, but it stops running after every change. That background analysis was designed for manual coding. In agentic workflow, the agent compiles when needed.

If the workspace shows a loading progress for the submodule, cancel it. The source code is still there for the agent to read.

Applying This to Real Projects

This workshop starts from an empty app. Mine is ten years old.

Start by adding the process, not by rewriting the app.

Add skills, rules, and AGENTS.md. Then ask the agent to read the existing code and create specs/tech-design.md that describes how the app works today.

Next, ask it to group existing functionality into high-level features and create a roadmap where those features are already marked as done. If there are no tests, ask it to generate tests from the current behaviour and run them until they pass.

Will these tests be perfect? Of course no. But they give you a starting safety net.

Do not create a full feature spec folder for every feature from the last ten years. That is too much. High-level technical design plus roadmap is enough to start the next feature in the SDD loop.

A dependency only exists as symbols.

Symbols tell the agent what exists. Objects, fields, procedures, signatures.

They do not tell the agent how the code behaves.

For high-level design, this is important. If source code is available, mount it. That is why the base code step exists.

For your own app, don't make the agent guess from symbols. You have the source code. Give it the source code.

A consultant already wrote the functional design. Where does the one-page brief fit?

The functional design is your brief.

In this workshop we start from a short customer note because that is the scenario. In your company, the functional design can be much more detailed. Good. Use it.

Ask the agent to turn that functional design into specs/tech-design.md, using three context sources:

1. Business Central source code.
2. Microsoft Learn.
3. Your existing repo.

If requirements live in Jira, connect the Atlassian MCP and let the agent read the issue and comments. Then, when the feature is done, the agent can also write the update back to the consultant: deployed to UAT, user docs are here, please test.

BC Quality reviewed the agent's code, and I don't know if either of them is right.

You still approve the result.

BCQuality is useful, but it is still young. I recommend forking it into your company and consuming your fork as a submodule. Then you decide when new rules are pulled in.

Read the diff. If the code is in an area you don't know well, like ControlAddIn or JavaScript, tests become your source of confidence.

Not understanding every line is not a reason to skip review. It is a reason to test the behaviour harder.

How do we roll this out without freezing the company?

Start with one or two pilot projects.

Small team. Real development work. Preferably not the oldest and most painful legacy app in the company.

The first project will be slower. You are not only building features. You are also building the company workflow: template repo, skills, rules, review process, and habits.

The second project is faster because it inherits all of that.

This is the math: don't convert the whole company at once. Build the pattern, prove it, then spread it.

Back to the build ->