Short answer: an agent runs a four-phase loop — assess state, pick a tool, receive a result, decide the next step. The model in this arrangement has no access to your data: it sees descriptions of available operations and whatever those operations returned. The entire security model rests on that boundary.
The loop: four phases
Each step of an agent is one pass through the loop. There may be two passes or twenty; the number is not known in advance and depends on the data.
- Assess state. The agent holds a goal, the history of previous steps and the list of available tools. From that it decides whether the goal is met.
- Pick a tool. If not, it selects an operation from the list and forms its parameters — "get overdue invoices" with a threshold and a date, for example.
- Execute. The integration layer validates the parameters, authenticates against Business Central and runs the query. Business Central applies the identity's permissions and returns a result or a refusal.
- Interpret. The agent sees what came back, adds it to the history and returns to phase 1.
Phase 3 is the important one. The model does not execute the query itself: it forms an intent. The integration layer executes, and it decides whether such a call is permissible at all. That is not an implementation detail — it is the foundation of the whole security model.
What the agent sees instead of a database
A common misconception is that the agent has "been given access to the ERP". What it actually receives is far narrower: a list of described operations with defined parameters.
One tool looks roughly like this — name: "get overdue receivables"; description: what it returns and when to use it; parameters: minimum amount, days overdue, company code. That is all. The agent cannot ask to "run an arbitrary query", because no such operation exists on the list.
Two consequences worth understanding before a project starts.
First: the agent's capabilities equal the tool list. Want it to do something new, and you build a new operation. That is not a limitation but what makes the system predictable and reviewable: the list can be printed and read.
Second: description quality drives behaviour. A poorly described tool gets called at the wrong moment or with unhelpful parameters. That is a correctness problem rather than a security one, but it is real, and a noticeable share of debugging goes into it.
A worked example
Goal: "prepare reminders for customers more than 30 days overdue above €5,000, excluding anyone with an open dispute."
| Step | What the agent does | What comes back |
|---|---|---|
| 1 | Calls "get overdue receivables" with thresholds | 14 customers, 31 documents |
| 2 | Calls "check open disputes" per customer | Two have disputes |
| 3 | Excludes those two, 12 remain | — |
| 4 | Calls "get open orders" for the 12 | Five have open orders |
| 5 | Groups documents by customer, drafts text | 12 drafts |
| 6 | Flags five where shipment may be worth holding | — |
| 7 | Stops: a person decides from here | Result for review |
Note step 2. The agent did not know in advance how many customers there would be, so the number of calls was determined at run time. That is what separates it from a Power Automate flow with a predefined sequence.
And note step 7. It stops not because the agent "decided to be careful" but because no "send reminder" operation exists in its tool list.
Memory and state
Within a single task the agent holds the history of steps: what it called, what it received, what has already been accounted for. That is its working memory, and it is finite — on long chains, early steps have to be compressed into a summary.
The practical consequence: very long tasks are less reliable than a series of short ones. An agent processing two hundred customers in one pass behaves worse than one invoked two hundred times for a single customer. This shapes how a scenario is designed, and it is one reason a broad first scope is a bad idea.
Between runs the agent remembers nothing by default. If it needs to know about previous actions — not sending the same reminder twice in a week, say — that memory has to be built deliberately: either as a record in Business Central or as separate state storage. Where possible the first is better, because the data stays visible to people and survives replacing the agent.
When an agent stops
Four legitimate reasons, all of which must be designed in explicitly:
- The goal is met — the result is ready.
- It reached a point where a person decides — by process design.
- The required operation is not on the list — it reports that it cannot continue.
- The step limit is exhausted — a guard against an endless loop.
The last is mandatory. An agent unable to reach its goal is capable of circling, trying variations of the same call. A step limit turns that from a problem into a log entry.
What happens on failure
This is where the line falls between a production-ready system and a demonstration.
Permission refusal. Business Central returns a refusal, the agent sees it and must report that the operation is unavailable. The correct behaviour is to say so rather than look for a workaround.
Empty result. The most dangerous case. The query ran and returned nothing. The agent has to distinguish "there is no data" from "something went wrong", and must never fill the gap with a plausible assumption. This is verified by separate testing rather than assumed.
Partial failure. Of twelve customers, three calls failed. The agent should complete for the nine and report the three separately — not stop entirely, and not pretend there were nine all along.
Throttling. Cloud Business Central limits call intensity. An agent making hundreds of small calls hits it. The fix is operation design: one call returning what is needed instead of twenty returning fragments.
What to monitor in production
A minimum set of metrics worth having from day one:
- Average steps per task. A sharp rise means the agent has started wandering.
- Share of tasks ending at the step limit.
- Permission refusals. If this is not zero, either the tool list is broader than the rights, or somebody is using the agent for something it was not built for.
- How much prepared work people reject. The key quality measure: if half of it gets discarded, the agent is creating work rather than removing it.
The last metric matters more than all the technical ones. An agent that is flawless in the logs and whose output gets redone every time is a failed project with good monitoring.
Frequently asked questions
Does the model have direct access to our database?
No. The model forms an intent to call an operation; the integration layer executes it — validating parameters, authenticating and calling Business Central, which applies the identity's permissions. The model sees only what came back.
How many steps does an agent take per task?
Not known in advance: it depends on the data. A typical narrow task runs three to fifteen steps. A step limit is mandatory, otherwise an agent unable to reach its goal can circle through variations of the same call.
Does the agent remember previous runs?
Not by default. If it must avoid repeating actions — not sending the same reminder twice, for example — that memory is built deliberately, ideally as a field in Business Central where it stays visible to people.
What happens if a query returns nothing?
A correctly designed agent distinguishes 'no data' from 'an error occurred' and reports both. Filling the gap with a plausible assumption is the most dangerous behaviour in a financial context, and it is verified by separate testing.
Why are long tasks less reliable?
Working memory is finite. On long chains early steps get compressed into a summary and detail is lost. A series of short runs behaves more consistently than one pass over two hundred records.
How do we know the agent is working well?
The main measure is how much of its prepared output people reject. If it is half, the agent is creating work rather than removing it — and technical logs will not show that.