Before your AI agent acts, look at how it decides
Take a supplier onboarding file. The agreement is signed and the insurance is current. The security review is missing. An agent handling the file needs to identify that missing review, keep the work already done and check the decision again when the review arrives.
An ordinary case like this says a lot about what an agent needs at work: facts it can access after the conversation, a rule that defines what follows from them, and permission for its next action.
But the facts rarely arrive ready to use. The supplier’s name is in the agreement, the expiry date is on a certificate and the review is in another document. Those pieces need to be connected before the team can use them.
ReasoningLayer automates part of that knowledge structuring. Extraction can use a model to identify entities, attributes and relationships; engine checks test their compatibility with the knowledge model and their references. Uncertain matches and fidelity to the sources need review. The team then has a knowledge base it can query and enrich as more files arrive.
From incoming sources to decision support
- Agreement
- Insurance certificate
- Security review
Structured knowledge linked to its sources
Supplier → agreement · insurance · review
Check types and references; review uncertain matches
Analysis and mining
Compare records and look for shared properties.
Decision support
Show which conditions hold and which evidence is missing.
Across the portfolio, data analysis helps answer practical questions: which files are waiting for a review? Which suppliers meet the declared conditions? Data mining can look for shared properties and surface groups worth examining. Its scope and search limits matter: a pattern in a sample does not necessarily describe every supplier or establish why a delay occurred.
That gives the buyer decision support. They can compare eligible files against their criteria, see why another is blocked and identify the evidence needed to reconsider it. They retain the final decision where the workflow calls for it. The engine computes consequences from facts and rules; a language model can explain the result, request evidence or prepare a proposal.
What the conclusion rests on
Agreement
Signed
Insurance
Valid
Security review
Favourable
Read the example rule
A supplier is ready when its agreement is signed, its insurance is valid and its security review is favourable.
The example rule is deliberately simple. A signed agreement, valid insurance and a favourable security review establish that the supplier is ready under this policy. The conclusion covers those particular conditions. The quality of the documents and the suitability of the rule still need checking.
This is where reasoning contributes to the workflow. The engine connects premises to a conclusion that no single document necessarily states. An explicit derivation can show which facts and rules produced the result.
A reviewer can work backwards from the conclusion to its supporting evidence. That provides an explanation they can inspect and challenge. Interpretability also comes from the business model: they can read the rule, correct a fact or change a condition, then inspect the next check. This visibility covers the engine’s knowledge and reasoning; the connected LLM remains a separate component.
The file keeps changing. A favourable review allows the conditions to be established. An unfavourable review leads to a different decision. While the review is absent, the waiting state needs to remain visible.
The next step changes when evidence arrives
Security review missing
Awaiting evidence
Favourable review
Ready under this policy
Unfavourable review
Rejected under this policy
The path through the work therefore depends on the available evidence. Checks that support waiting for evidence can remain pending in the engine and resume when that evidence arrives. The integration connects incoming data to these checks and their results to business tools.
That continuity can outlast an agent session. Another authorized person or agent can retrieve the recorded facts, references and saved decisions. You still choose what to capture and how to keep the sources current; conversation history does not automatically become a reliable knowledge base.
Now suppose the agent prepares a supplier-summary export for the purchasing team. A reviewer approves 100 rows to an internal workspace. The next proposal asks for 200 rows. Same agent, same dataset, same destination; the volume has changed.
The approval covers a particular action
Recorded approval
- Request
- Export #42
- Dataset
- Supplier summary
- Destination
- Internal workspace
- Volume
- 100 rows
Next proposed export
- Request
- Export #42
- Dataset
- Supplier summary
- Destination
- Internal workspace
- Volume
- 200 rows
The approval for 100 rows does not cover 200.
For a sensitive operation, permission needs to cover the particular action being executed. ReasoningLayer provides policy checks, scoped knowledge access and action-review mechanisms. The execution connector needs to enforce their result. That is where governance becomes a workflow control.
Stability takes similar work. A review can be withdrawn, insurance can expire and policy can change. The team needs to recover the inputs and rules used, rerun the checks and compare results with known cases. A change of LLM can then be tested without rewriting the business rules. Pending or resource-limited results must remain distinguishable from completed checks. Availability and recovery require their own deployment tests.
The model does not always need the whole file. To explain a decision, the result and its relevant references may be enough. The rest of the knowledge stays in the database, available for the next question.
Two memory costs to account for
Persistent knowledge base
- Supplier records
- Rules and relationships
- Supporting references
Engine RAM, indexes and working memory
Context for the current task
- The question
- The relevant result
- References needed for the answer
Model weights and KV cache in RAM or VRAM
This division gives a cost lever: some structured queries and reasoning can run outside LLM generation, and the context sent to the model can be shorter. For local inference, that can reduce demand on the KV cache, the memory that retains attention state during generation.
The total also includes the engine’s RAM, model weights and inference-server allocations. A reserved GPU pool can remain allocated even when requests use less of it. A useful comparison measures the whole workflow at comparable quality and load. The diagram does not establish a universal percentage saving. The KV-cache documentation explains the model-side tradeoffs.
Where the components run matters too. Self-hosting lets you choose where the knowledge engine operates. Control of the data boundary also requires decisions about models, connectors and logs. With a remote LLM, the information sent to it needs to be defined and controlled. That belongs in a deployment review before claiming end-to-end sovereignty.
Retrieval can find the documents; the engine can connect their facts and apply rules; the LLM can write the explanation. Our articles on access control and interactive scheduling show concrete uses of explicit data and computation.
To evaluate this approach, start with your sources and a real file: complete, incomplete or rejected. Look at the structuring effort, useful comparisons, what the agent concludes and what a reviewer can check before acting. Processing time, review effort and total cost then give your team a useful comparison.