Skip to main content
All posts
October 28, 20266 min readReasoning Layer team

Before your AI agent acts, look at how it decides

AI agentsdynamic workflowsreasoninggovernancesovereignty

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
Extract entities, attributes and links

Structured knowledge linked to its sources

Supplier → agreement · insurance · review

Check types and references; review uncertain matches

Query and explore the recorded data

Analysis and mining

Compare records and look for shared properties.

Decision support

Show which conditions hold and which evidence is missing.

An illustrative path through the work. Extraction proposes knowledge; mining surfaces patterns to examine. The source material still needs review.

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

All three conditions
If these three facts are established
Ready under this policy
Read the example rule

A supplier is ready when its agreement is signed, its insurance is valid and its security review is favourable.

Illustrative rule. The conclusion depends on the supplied facts and policy; it does not authenticate the documents.

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

The review arrives

Favourable review

Ready under this policy

Unfavourable review

Rejected under this policy

Two possible outcomes for the same file. Notifications and external actions belong to the connected workflow.

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.

The new scope needs its own policy and approval check. An approval does not override the other rules.

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

Selected result and evidence

Context for the current task

  • The question
  • The relevant result
  • References needed for the answer

Model weights and KV cache in RAM or VRAM

A possible division of work, with no implied memory ratio. Placement and resource budgets depend on the deployment.

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.