Practitioner-grade definitions for 88+ terms across RAG, GraphRAG, agents, LLMOps, voice AI, knowledge graphs and production patterns. Maintained by the engineers who ship Cognilium's production AI systems, which is why the definitions say what a term costs you as well as what it means.
88
terms defined
8
categories
0
terms defined by a marketing team
A class of algorithms that find vectors close to a query vector quickly without scanning the full index, trading exact correctness for speed.
HNSW, IVF-PQ, and ScaNN are common ANN algorithms. Used by Pinecone, Qdrant, Weaviate, and pgvector. Recall is typically tuned to 0.95-0.99 of exact search.
A keyword-based ranking function that scores documents against a query using term frequency, inverse document frequency, and document length normalization.
BM25 (Best Matching 25) is the lexical-search baseline. Hybrid retrieval combines BM25 with vector search via score fusion (RRF — Reciprocal Rank Fusion) to capture both keyword precision and semantic recall.
The process of splitting documents into smaller passages (chunks) for embedding and retrieval.
Common strategies: fixed-size (e.g., 512 tokens), recursive character splitter, semantic chunking by sentence/paragraph boundaries, structural chunking (headings, lists). Chunk size + overlap is one of the highest-impact RAG knobs.
Retrieval-augmented generation that queries a property graph instead of (or alongside) a flat vector index to capture entity relationships during retrieval.
GraphRAG wins above ~100k documents or when queries require multi-hop reasoning. Architecture is 4 layers: extraction, graph store, hybrid retrieval, answer synthesis. Costs 1.5×-3× more than vector RAG but lifts answer accuracy on relationship-heavy queries by 30-50%.
Retrieval that combines lexical (BM25), semantic (vector), and sometimes graph-based methods to maximize both precision and recall.
Fusion is typically via Reciprocal Rank Fusion (RRF) or weighted score averaging. Hybrid retrieval almost always outperforms any single method on enterprise corpora.
A pattern where an LLM is given retrieved context (passages, facts, code) at inference time to ground its answer, instead of relying purely on training-time knowledge.
RAG decouples the model from the corpus. Documents are embedded into a vector index; at query time, top-k similar chunks are retrieved and prepended to the LLM prompt. This pattern enables citation, freshness, and domain specialization without re-training.
A second-stage scoring step that re-orders retrieved candidates using a more expensive but more accurate model (typically a cross-encoder or LLM).
Cohere Rerank 3, Jina Reranker, and cross-encoder models like BGE-reranker are typical choices. Reranking the top 100 candidates and keeping the top 5-10 outperforms larger flat top-k retrieval.
Search that retrieves documents by meaning (via embeddings) rather than exact keyword match.
Sometimes used interchangeably with vector search. Distinguishes from lexical search (BM25, TF-IDF) which matches surface forms.
A dense numerical representation of text (or image, audio) that captures semantic meaning in a high-dimensional space, used for similarity search.
Modern embeddings come from models like OpenAI text-embedding-3-large, Cohere embed-v3, or open-weight Nomic and BGE. Typical dimensions: 768-3072. Cosine similarity is the default distance metric.
The maximum number of tokens an LLM can attend to in a single inference call, combining input and output.
Context windows have grown from 4k tokens (2022) to 1M+ tokens (Gemini 1.5 Pro, Claude 4.6 Sonnet) in 2026. Long context enables document-stuffing patterns but does not eliminate the need for RAG — retrieval-quality and cost both still favor selective context.
Training a smaller student model to mimic the outputs of a larger teacher model, reducing inference cost while preserving most capability.
Used to create Anthropic Haiku from Sonnet, OpenAI 4o-mini from 4o, etc. Production teams distill task-specific behaviors from frontier models into cheaper open-weight models for hot paths.
Updating a pre-trained model's weights on a smaller, task-specific dataset to specialize its behavior.
Modern fine-tuning is usually LoRA (low-rank adaptation) or QLoRA — parameter-efficient methods that update a tiny fraction of weights. Production fine-tuning for AI applications is rarer in 2026 than 2023; RAG + prompt engineering covers most needs.
A large model trained on broad data and adaptable to many downstream tasks via prompting, fine-tuning, or RAG.
Foundation models include LLMs, vision-language models (CLIP, Gemini Vision), speech models (Whisper, Ultravox), and multimodal models. The term highlights that one base model serves many applications.
A transformer-based neural network trained on large text corpora to predict next tokens, ranging from 1B to 1T+ parameters.
Examples: Anthropic Claude (Fable, Mythos, Opus, Sonnet, Haiku), OpenAI GPT (4o, 4.1, 5), Google Gemini, Meta Llama. Most production AI in 2026 is built on closed-weight LLMs accessed via API.
A model architecture where different "expert" sub-networks handle different inputs, activating only a subset of parameters per token.
MoE models (Mixtral, DeepSeek-V3, Llama 4) have high total parameter counts but lower active parameters per token, enabling cheaper inference. Most frontier models in 2026 are MoE under the hood.
Reducing the numerical precision of a model's weights (e.g., fp32 → int8 or int4) to shrink memory and speed inference.
Common quantization levels: fp16, bf16, int8, int4. Open-weight models served via vLLM, llama.cpp, or TensorRT typically run quantized in production. Quality degradation is minor for most tasks above 4-bit.
A training technique where humans rank model outputs and the model learns to prefer high-ranked responses through a reward model.
RLHF is how foundation labs (Anthropic, OpenAI) align models for helpfulness and safety. Most production teams do not do RLHF; they consume aligned models via API and use prompting/RAG to specialize.
An LLM-driven system that observes, plans, takes actions through tools, and observes results in a loop to accomplish a goal.
Distinguished from a single prompt by the loop structure: think → act → observe → repeat. Production agents have evaluation, retries, cost caps, and human-in-the-loop checkpoints.
AWS's managed agent runtime with built-in observability, memory, and tool integration, available as part of Amazon Bedrock.
Best fit when the rest of the stack is AWS-native and the customer requires data residency, VPC integration, or BAA. Cognilium has shipped production multi-agent systems on AgentCore.
A Python framework for orchestrating role-based multi-agent systems with declarative task assignment.
CrewAI uses a "crew of agents with roles" mental model (researcher, writer, editor). Simpler API than LangGraph for role-based workflows; less flexible for arbitrary state machines.
A Python library from LangChain Inc. for building agent workflows as explicit state-machine graphs with typed state and conditional edges.
LangGraph beats raw LangChain agents for production reliability because state is observable and transitions are explicit. Combined with LangSmith for trace observability, it is a common production stack choice.
An architecture where multiple specialized agents collaborate, often coordinated by a supervisor or router agent.
Common pattern: supervisor agent routes tasks to specialist agents (researcher, coder, reviewer). Worth the complexity only when single-agent context limits or capability gaps are hit. Costs and failure modes compound.
An agent loop where the LLM alternates between Reasoning (thought) and Acting (tool call), used in early agent frameworks.
Original ReAct paper (Yao et al., 2022) inspired LangChain agents. Modern frameworks (LangGraph, CrewAI) generalize beyond pure ReAct with state-machine and DAG patterns.
A multi-agent architecture where a top-level supervisor agent dispatches subtasks to specialist agents and aggregates their results.
Used in Cognilium-built production systems on AWS Bedrock AgentCore and Google ADK. Supervisor binds only the tools each tenant has access to, preventing forked agent definitions per customer.
An LLM capability where the model emits structured calls to external functions (APIs, code execution, search) and incorporates their results into its response.
All frontier LLMs support tool use in 2026. The model decides when to call which tool based on the prompt and tool schemas. Production tool use needs strict schemas, retry logic, and timeout handling.
The SQL-like query language for property graphs, originally from Neo4j, now supported by Memgraph, Neptune (openCypher), and others.
Example: MATCH (c:Company)-[:EMPLOYS]->(p:Person) WHERE c.industry = "Finance" RETURN p.name. Industry-default query language for knowledge graphs.
The process of deciding when two surface forms ("Acme Corp", "Acme Corporation") refer to the same real-world entity.
Combines canonical-name lookup, embedding similarity, and rule-based identifiers (DUNS, EIN, addresses). Without it, knowledge graphs accumulate duplicate identity nodes and retrieval over-fetches.
The silent decay of a production knowledge graph's correctness through orphan nodes, duplicate entities, stale edges, and missing provenance.
Cognilium monitors 7 specific decay signals — orphan rate, duplicate identity, edge staleness, source-document drift, attribute conflicts, cycle pollution, and provenance gaps — with weekly health checks.
The process of walking from one node to others through edges, typically to assemble retrieval context or answer multi-hop queries.
Production graph traversal has depth caps (typically 2) and fanout caps per node (50-100) to prevent cost explosions on high-degree hub entities.
A data structure of typed entities (nodes) and typed relationships (edges) with attached attributes, used to represent domain knowledge.
Distinguished from a flat database by the graph topology and the focus on relationships. Cognilium builds production knowledge graphs for legal, financial, and HR use cases on Neo4j, Memgraph, and Amazon Neptune.
A formal specification of the entity types, relationship types, and constraints in a knowledge graph schema.
The ontology defines what is possible: "Person can EMPLOYED_BY Organization", "Contract REFERENCES Section". Ontology design is engineering, not an LLM task — sloppy schemas lead to graph rot.
A graph data model where both nodes and edges can have typed properties (key-value pairs), used by Neo4j, Memgraph, and Neptune.
Contrasts with RDF triples (subject-predicate-object), which are more rigid. Property graphs are the production default for knowledge-graph applications outside academic semantic web.
A pattern that halts requests to an LLM endpoint when error rates or latency exceed thresholds, allowing the system to fail closed rather than degrade.
Borrowed from microservices reliability. Production LLM systems set circuit breakers per provider (Anthropic, OpenAI, Bedrock) and route to fallback providers when a circuit opens.
A workflow where prompt and architecture changes are scored against a golden test set of queries before deployment.
Analogous to test-driven development for traditional software. Golden sets cover 100-300 queries spanning happy path, edge cases, and adversarial inputs. Scoring uses LLM-as-judge or human review.
A curated collection of input-output pairs used as the regression suite for LLM applications.
Maintained continuously: new failure modes from production logs get added; stale examples get pruned. Without a golden set, "is this prompt change better?" is unanswerable.
Using an LLM to score the output of another LLM against a rubric, replacing expensive human evaluation for scalable quality measurement.
Production judges include temperature-escalation retry patterns (retry at higher temperature if judge score is low) and ensemble judging (3 judges vote). Judges have known failure modes — verbosity bias, position bias.
The operational discipline of running LLM-powered applications in production — evaluation, observability, retries, cost engineering, prompt versioning.
LLMOps is to LLM applications what MLOps is to traditional ML. Stack components: golden-set evaluation, LLM-as-judge, LangSmith/Langfuse for traces, Helicone for token observability, circuit breakers, prompt versioning.
The ability to inspect and debug LLM application behavior in production through traces, logs, metrics, and cost data.
Standard stack in 2026: LangSmith or Langfuse for traces, Helicone for token-spend metering, Datadog for infrastructure metrics, OpenTelemetry GenAI conventions as the open standard.
The practice of designing the instructions, structure, and examples given to an LLM to elicit a desired behavior.
In 2026, prompt engineering is less brittle than in 2023 because models are more aligned, but still consequential. Production prompts are versioned, tested against golden sets, and A/B tested.
The discipline of managing per-request and aggregate cost of LLM applications through routing, caching, batching, and model selection.
Levers: route trivial queries to cheaper models, cache repeated queries with semantic-similar lookup, batch where latency permits, prefer prompt caching when supported. A 70% cost reduction is typical without quality loss.
The capability of a voice agent to detect when a user has started speaking over its response and gracefully stop, allowing natural conversation.
Engineering challenges: distinguishing real interruption from background noise, handling cut-off responses cleanly, recovering conversational state. Standard in production-grade voice systems.
The maximum allowed end-to-end response time for a voice agent, typically budgeted across VAD, STT, LLM, TTS, and network legs.
Industry target: sub-1.5 seconds p95. Typical 2026 budget: 200ms VAD + 250ms streaming STT + 500ms first-token LLM + 300ms first-byte TTS + 250ms network = 1.5s. Each hop is where engineering effort goes.
A single model that goes directly from spoken input to spoken output without an intermediate text representation, reducing latency and preserving prosody.
Ultravox and OpenAI Realtime are leading production options in 2026. Removes 2 of the 3 latency hops (STT → LLM → TTS becomes one model), enabling sub-600ms first-token responses.
The transcription of spoken audio into text. Modern STT supports streaming (partial transcripts during speech) for low-latency voice agents.
Production options: Deepgram Nova, AssemblyAI, OpenAI Whisper. Deepgram and AssemblyAI lead on streaming latency; Whisper is the open-weight default for batch transcription.
The synthesis of natural-sounding speech from text input, with streaming support for low-first-byte voice agents.
Production options: ElevenLabs (highest naturalness, branded-voice cloning), Cartesia (low latency), Azure Neural, Google Cloud TTS. Streaming TTS shaves 200-400ms off first-token latency.
AI systems that interact via spoken language, typically combining speech-to-text (STT), an LLM, and text-to-speech (TTS), or using a single speech-to-speech model.
Production voice AI in 2026 includes call-center agents, voice assistants, voice interview systems, and voice-augmented support. Latency budget (sub-1.5s p95) is the dominant engineering constraint.
When an embedding model is updated and previously-indexed vectors are no longer comparable to new query embeddings, requiring full re-embedding.
A real operational concern when changing embedding models (e.g., text-embedding-ada-002 → text-embedding-3-large). Production teams version embedding models and gate model upgrades on full corpus re-index.
A structured API where the LLM returns a JSON description of a function to call (with arguments) rather than free text, enabling tool use.
All frontier APIs (Anthropic, OpenAI, Google) support function calling. Production-grade implementations enforce JSON schema validity, retry on malformed outputs, and timeout on long-running tools.
The practice of constraining LLM outputs to be supported by retrieved context, cited sources, or a controlled vocabulary.
Strongest grounding: instruct the model to refuse if no supporting context is provided, require inline citations, validate citations exist in the corpus, and post-process outputs to reject claims without backing.
When an LLM produces a confident-sounding output that is not grounded in the input context or in verified facts.
Hallucinations cannot be fully eliminated but are dramatically reduced through grounding (RAG), domain vocabulary enforcement, output validation, and instruct-cite-or-refuse prompting.
An adversarial input that hijacks an LLM's instructions, causing it to ignore the system prompt or leak sensitive information.
Defenses: input filtering, dual LLM (one parses the input untrusted, one acts on a sanitized version), strict output schemas, system-prompt isolation. No defense is complete; assume some leakage.
A cache where lookups are by semantic similarity of queries (via embeddings), not by exact match, allowing reuse of LLM responses for paraphrased queries.
Production semantic caches (Redis vector, GPTCache) hit on 20-40% of queries in domains with repeat patterns (FAQ, support). The cost saving is multiplicative on LLM spend.
The programming language for extending Business Central, written against a published extension model rather than by modifying base code.
Extensions are installed alongside the base application and survive updates by design, which is what makes Business Central's continuous update cadence workable. The constraint is the other side of the same coin: you can only extend where the base application offers an extension point.
Microsoft's marketplace for business applications, where Dynamics 365 customers browse, filter and install third-party apps.
AppSource is a discovery surface as much as a distribution one — buyers filter by category and industry and read ratings there. Notably, its category taxonomy has no "optimization" entry, so vendors describe themselves in the buyer's vocabulary rather than their own.
The rule Dynamics 365 Business Central uses to resolve a sales price: the lowest permissible price with the highest permissible line discount on a given date.
It ranges over prices that already exist — entries someone has recorded in a sales price list, a customer price group or a line discount. The system selects among them deterministically. It does not evaluate whether any of those prices was the right one to have entered, which is a separate, data-driven question.
Microsoft's ERP for small and mid-sized organisations, extended in the AL language and updated on its own release cadence.
It is a different product from Dynamics 365 Finance and Operations, not a smaller edition of it — different data model, different extension language, different administration. Treating "Dynamics 365" as one product is where a large share of expensive platform decisions begin.
Microsoft's brand for the AI assistants embedded in its products. In Dynamics 365 it names an in-app chat surface, not a single capability.
What a Copilot can reach is decided by what it has been connected to, so two deployments carrying the same name can differ completely in scope. The in-app panel answers over product documentation by default; answering over a customer's own transactional data is a separate configuration, not an included behaviour.
Microsoft's low-code environment for building custom agents — defining their instructions, knowledge sources, tools and publishing targets.
It is where an organisation moves from the assistant Microsoft ships to one scoped to its own processes. Agents built here consume metered capacity, so their running cost is a function of how often they are called and how much work each call does.
The setting that decides the shape of every replenishment order for an item — per requirement, batched into a period, held between a minimum and maximum, or not planned at all.
Assigned on the coverage group and overridable per item and site. It is the single most consequential planning parameter, and it is usually inherited from an implementation default rather than chosen per item class.
A Business Central grouping that lets one price apply to a set of customers rather than to each customer individually.
Paired with customer discount groups, it is how most mid-market Dynamics installations express commercial policy. The grouping is manual, and it is rarely revisited once set, which is where realised price starts drifting from intended policy.
Microsoft's managed data platform underneath Dynamics 365 and Power Platform, providing storage, security and an API surface inside the customer's own tenancy.
Dataverse-native apps run inside the governed environment rather than beside it, which is usually the detail that decides an IT buyer: no export of customer, pricing or inventory history to an external service.
A replenishment method that positions decoupling buffers at chosen points in the supply chain and plans to buffer levels rather than to a forecast.
Dynamics 365 supports it as a coverage option, with prerequisites: it depends on Planning Optimization and carries its own licensing qualifiers. It is a methodology with a certification body behind it, not merely a checkbox, and adopting it changes how planners work as much as how the engine runs.
Forecasting future demand — a separate discipline from master planning, which consumes the forecast rather than producing it.
The forecast lives in its own application with its own algorithms and its own versioning. Whether a sales order consumes the forecast it was forecast against, or is planned on top of it, is a configuration decision — and getting it wrong double-counts demand.
Microsoft's enterprise ERP for finance, supply chain, manufacturing and commerce, extended in X++ and administered separately from Business Central.
Sometimes written F&O or "Finance & Operations apps". It carries the deeper supply-chain functionality — master planning, warehouse management, production — and a correspondingly heavier implementation. Choosing between it and Business Central decides the extension language, the update cadence and the administration model at once.
How much actual supplier delivery dates move around the planned lead time held in the ERP.
ERPs store a single planned lead time per item or vendor. What determines the buffer you need is the spread around it, which is measurable from receipt history against purchase orders. It is usually larger than expected, and it is the term most often assumed rather than measured when safety stock is set.
Microsoft's long-standing portal for managing Finance and Operations projects, environments and deployments.
Its responsibilities are moving to the Power Platform admin center, and new project creation has already been closed for new customers of several products. Anything written on the assumption that a task happens in LCS needs re-checking against the current administration surface.
A percentage reduction applied to a sales line in Dynamics 365, configurable by item, customer or discount group and layered on top of the resolved price.
Line discounts, invoice discounts and one-off overrides compound. The price actually invoiced is frequently some distance from list, and the gap between the two is where margin is lost without anyone having decided it should be.
A Dynamics 365 Supply Chain Management rule that decides which warehouse location is used for a put-away or pick operation.
Location directives are how the ERP executes a placement policy consistently. They enforce the decision; they do not derive it. The question of which policy would minimise travel is answered from order history, not from configuration.
The cumulative difference between the price a business intended to charge and the price it actually invoiced, once discounts, overrides and stale price lists are accounted for.
It is rarely one large concession. It is many small ones that no single approval caught, visible only when realised price is compared against list across a long enough history and segmented by customer and item.
Dynamics 365's name for MRP: the run that nets demand against supply and emits planned orders according to each item's replenishment policy.
It is a calculation, not a decision. It executes the coverage settings, safety stock and time fences it was given, faithfully and fast, and has no opinion about whether any of them are still right. The policy is where the judgement lives, and the engine does not supply it.
An open protocol that lets an AI agent call a system's functions as named tools, instead of driving its screens or scraping its output.
A server exposes tools; a client model calls them with structured arguments and receives structured results. For an ERP this matters because the alternative — automating the user interface — breaks whenever a form changes. Microsoft ships an MCP server for Dynamics 365 Finance and Operations, which is what makes an agent's reach a configuration decision rather than a scripting exercise.
The calculation that turns demand, current inventory and planning parameters into suggested supply orders.
MRP is deterministic and does exactly what its parameters instruct. It is not a forecasting engine and it does not evaluate its own inputs: given a safety stock level that is too low, it will plan faithfully to that level and the stockout will look like bad luck rather than a bad parameter.
Microsoft's policy of keeping every Finance and Operations customer on a continuously updated version, rather than allowing long-lived releases.
Updates arrive on a published cadence with a bounded pause allowance. It guarantees everyone is on supported code; it does not guarantee that a given feature will not change, which is why regression testing becomes a standing commitment rather than a project phase.
The route a picker takes through a warehouse to collect the lines on an order.
Pick path length is a function of two things: the sequence the system releases lines in, and where the items are stored. Optimising the route alone hits a ceiling set by placement, which is why slotting and routing are usually solved together.
The current master-planning engine for Dynamics 365 Finance and Operations, running as a cloud add-in rather than inside the ERP database.
It replaced the built-in engine, which Microsoft has stopped investing in. Because it runs as a service it is cloud-only, and a subset of the older engine's behaviours is deliberately not carried over — which is why a migration is a fit assessment rather than a switch.
The Business Central screen where MRP is run and its supply suggestions are reviewed before being turned into orders.
The worksheet compares net inventory position against open demand and the safety stock buffer, then proposes supply. Planners commonly describe running it and then working through a flood of cancellation and rescheduling messages — a symptom of planning parameters that no longer match reality.
Microsoft's low-code application platform — Power Apps, Power Automate, Power BI — built on Dataverse and used to extend Dynamics 365 without modifying the ERP core.
For a Dynamics IT buyer this stack is the credibility layer: it is governed, it is already licensed, and it does not introduce a new security boundary.
Microsoft's twice-yearly feature release cycle for Dynamics 365 and Power Platform, published in advance as a release plan.
A plan date is not a ship date. A release plan entry can list a preview and a general-availability month and carry no released marker against either, and reading the plan as a commitment is how a roadmap becomes a promise nobody made.
The inventory level at which Dynamics 365 planning suggests a replenishment order.
A correct reorder point covers expected demand across the replenishment lead time plus a buffer for variability in both. Business Central stores the number; it does not compute it from demand or lead-time history.
The Business Central setting that decides how an item is replenished. Four options: Fixed Reorder Quantity, Maximum Quantity, Lot-for-Lot, and Order.
The policy determines the shape of the supply suggestion; the planning parameters determine its size. Choosing the right policy per item is a judgement call that has to be made thousands of times, which is why in practice one policy is often applied across a whole item category.
A Business Central field holding the minimum quantity of an item you want to keep on hand. It also acts as the reorder point when no reorder point is specified.
MRP reads the field and plans replenishment to honour it, every run, faithfully. The number itself was typed by a person — usually at implementation, when there was no history to derive it from — and on most systems has not been revisited since. Nothing in the planning engine has an opinion about whether it is still right.
The Business Central table holding agreed prices, pointed at a customer, a customer price group, a campaign or all customers, and bounded by date.
Price lists are a system-of-record construct: they store a decision a person already made. They are combined with sales line discounts at order entry, and the best price principle picks the winner.
The permission set assigned to a user or an agent identity in Dynamics 365, controlling which data and operations it can reach.
For an agent this is the entire blast radius: there is no separate agent-permission layer beneath it. A narrower role also tends to make an agent more accurate rather than merely safer, because it shrinks the space of things the model can wrongly choose between.
The probability, chosen deliberately, of not running out of an item during a replenishment cycle.
A business decision rather than a statistical one, and it should differ between an item that halts a production line and an item a customer will wait a week for. Without a stated service level, "optimal" inventory has no meaning: you can always eliminate stockouts by holding more and always cut stock by accepting more of them.
A distinction between software that stores and enforces a decision (the system of record) and software that computes what the decision should be (the system of intelligence).
An ERP is a system of record by design: it holds the price list, the bin, the reorder point and the contract, and applies them consistently. Deriving those values from history is a different job with different requirements, and it is normally done in a companion application rather than inside the ERP.
A horizon that limits what master planning may see or change — how far ahead it plans, and how near-term it is permitted to overwrite.
Several exist and they do different jobs: a coverage time fence bounds planning, a freeze fence protects near-term orders from being rescheduled, a forecast fence governs where the forecast stops driving demand. Setting one from a default without comparing it to total lead time is a common and expensive mistake.
Deciding which storage location each item occupies, so that the travel required to fill orders is reduced. In Dynamics 365 Supply Chain Management it is also the name of a built-in feature.
Travel is roughly half of order-picking time, and where inventory lives determines how far anyone walks. The ERP records and enforces the location; deciding which location an item should occupy, given how it is actually ordered, is an operations-research problem rather than a configuration one.
The programming language for extending Dynamics 365 Finance and Operations, with a class and table model specific to that ERP.
Existing X++ business logic can be surfaced to an AI agent as a named tool, which is how an organisation exposes rules it already trusts rather than asking a model to re-derive them. The commitment is real: X++ skills are specific to this product and do not transfer to Business Central.