A different approach for agentic AI

Business Use case in a regulated industry (Europe)

May 31, 2026

Dear reader,

this article reflects my current learning progress. I have not built this yet. The idea, the concept, and the code examples are not mine, but from a friend. I have merely applied them to a fictional use case.

His solution is horizontal and not yet on the market. We will soon do a vertical PoC. As soon as it has been successful, we will publish who it is and what the solution is called.

The article may contain errors! I am happy if you point them out to me, because this is about learning together.

Thank you!

Not one framework for everything!

This article is about a fictional use case of a fictional company.

Please remember that not every approach fits every industry, every company size, and every use case!

Here are the key facts about what this article is about:

Industry: financial industry
Company size: 200 employees
Headquarters: Germany
Applicable laws and regulations: EU directives on investor protection and market transparency, EU requirements on sustainability reporting, German capital market and tax law, BaFin supervision and reporting obligations, EU requirements on digital operational resilience, EU regulation on the use of AI systems…

The Use Case

A portfolio manager reports regularly to investors and supervisory authorities on how the investments in the portfolio have developed and what risks exist.

For funds with a sustainability strategy, this mandatorily includes metrics such as the average carbon intensity (WACI, Weighted Average Carbon Intensity), which indicates how carbon-intensive the held companies are relative to their revenue.

The report must be verifiably correct, because incorrect or embellished figures have regulatory consequences and endanger investor trust!

This article

The article at first only describes the parts of the architecture that are different from other agentic AI systems
Then ontology is examined more closely, but the focus is on the practical application.
I explain a rough workflow and when and how the AI actually takes place.
The difference to an autonomous AI agent is made clear.
A few philosophical thoughts always have to be there!
And finally, what this has to do with the way of working, the organization, the operating model
and why business people should also read this!

It will certainly be partly hard to read. But it is worth it!

Architecture layers - work in progress

I do not have a diagram here, because it is a work in progress and I am not yet entirely sure about all the details. But what I have understood so far is that we need to consider the following things:

Ontology:

says what exists and what is valid
but does not say what values something has or may have
consists of several files

Decision space:

defines which actions are permissible, which states are traversed, and which guardrails apply
declarative, that is a list of what is permitted, not a calculator

Rule engine:

takes the domain-specific thresholds and applies them to the validated data
is deterministic code

AI model, LLM:

only formulates prose
It interprets text at the beginning, what the user wants, and then comes last at the very end to write the prose of the report
receives finished numbers and only writes text

What is ontology?

Honestly, I found it very hard to imagine what an ontology actually is when applied in practice. In theory it is simple. In practice it is a completely different matter.

Here is an attempt. I am not sure whether it is correct this way. But I do not want to bother my friend for hours every day with questions, so I am trying it via writing and a Substack discussion. Do you know your way around? Then please check whether it is correct!

Edit after publication:

I learned that the concept described in this article is not 100% a full ontology by the book. It is more a mixture of elements of a “lightweight ontology / semantic / domain modeling thingy”.

The goal of the article is to explain one possible concept how to use AI agents in a regulated industry.

It is NOT the goal of the article to explain the definitions of ontology, semantic, data or domain modeling or other topics.

The goal of the article is to explain a pragmatic way of building this. Nothing else. Thanks for your understanding.

The ontology is a bundle of several files that together only define two things:

what exists: vocabulary
and what a valid process looks like: validity

It never says what is allowed.

The philosophy behind it: Someone who works this way does not trust an LLM. You see the LLM soberly, as a tool, as a help. But under no circumstances as something that “knows” or “thinks” or “understands” or could even decide anything.

Building block 1: The nouns

The nouns are referred to here as resources.

These are the things that the report talks about at all:

Portfolio
Asset

They are listed in the file vocab.skos.jsonld as SKOS concepts

Simple Knowledge Organization System is a W3C standard for describing vocabularies and concept hierarchies

They are arranged hierarchically:

An asset belongs to a portfolio, expressed via skos:broader (one concept is broader than another).

{
  "@id": "fin:resource/portfolio",
  "@type": "skos:Concept",
  "skos:prefLabel": "Portfolio"
},
{
  "@id": "fin:resource/asset",
  "@type": "skos:Concept",
  "skos:prefLabel": "Asset",
  "skos:broader": "fin:resource/portfolio"
}

Building block 2: The verbs plus nouns

Verbs plus nouns are referred to here as intents.

These are the nameable actions, here: creating a report.

They are likewise listed in vocab.skos.jsonld and attach to their resource via skos:broader.

Each intent carries secondary labels (skos:altLabel), that is words with which a human could mean the same thing.

{
  "@id": "fin:intent/report.create",
  "@type": "skos:Concept",
  "skos:prefLabel": "Create Portfolio Report",
  "skos:altLabel": [
    "create the report",
    "create quarterly report"
  ],
  "skos:broader": "fin:resource/portfolio"
}

Building block 3: The synonyms

Via the thesaurus you build a bridge from language to the intended concept.

They are collected in thesaurus.jsonld and assign each formulation to a concept.

This way, what the portfolio manager types becomes an unambiguous concept address.

{
  "label": "create quaterly report",
  "alt": ["create the report"],
  "concept_id": "fin:intent/report.create"
}

Building block 4: The mapping with minimum confidence

File: intent-mappings.json

It connects the concept from the thesaurus with the official action label of the system.

It requires a minimum confidence (confidence_floor). In the model it is 0.75. If the recognition is below that, it is not executed.

{
  "concept_uri": "fin:intent/report.create",
  "intent_class": "fin.portfolio.report.create.v1",
  "confidence_floor": 0.75
}

Building block 5: The recognition patterns

File: patterns.json

Simple text patterns (Regex, Regular Expressions) plus examples that additionally assign raw text to a concept.

They are the fast, deterministic pre-check before fuzzy language assignment becomes necessary.

{
  "id": "fin_report_create_intent",
  "concept_uri": "fin:intent/report.create",
  "entity_type": "intent_hint",
  "regex": "(?i)^(create|make) .*report.*$",
  "examples": ["create the quaterly report"]
}

Building block 6: The shape rules (SHACL)

File: shapes.ttl

SHACL (Shapes Constraint Language) is a W3C standard for validating RDF data (Resource Description Framework).

The shape rules define which fields a valid process must have, and they check pure completeness, not permission.

For the report:

Every portfolio needs at least one asset, and every asset needs a CO2 Intensity Score.

fin:PortfolioShape
  a sh:NodeShape ;
  sh:targetClass fin:Portfolio ;
  sh:property [ sh:path fin:consistsOf        ; sh:minCount 1 ] ;
  sh:property [ sh:path fin:co2IntensityScore ; sh:datatype xsd:decimal ;
                sh:minCount 1 ; sh:maxCount 1 ] .

Distinction

All six building blocks above are exclusively vocabulary and validity.

They say what exists and whether a process is complete.
They say nothing about what may happen.

That happens in the decision space.

Decision space

The permissibility is stored in decision-space.json.

This file is declarative, that is a list of what is permitted, not a calculator.

It defines:

which actions exist
which states are traversed, in our example:
- ingress
- validated
- classified
- responded

which guards apply at each transition

Its only question is:

May this action take place at all in this state? It is the doorman with the guest list.

Rule engine

The calculation is in the rule engine. It is deterministic code that determines values and derives domain-specific consequences from them.

Example for this use case:

It calculates the weighted average carbon intensity (WACI, Weighted Average Carbon Intensity),
determines that 205 is above the threshold value 200,
and thereupon makes the section Carbon Mitigation mandatory.

It is not the doorman, but the calculator behind it.

This results in a clean three-way split:

Vocabulary and validity: the ontology (the six building blocks above). Declarative.
Permissibility and process: decision-space.json. Declarative.
Calculation and domain-specific consequence: the rule engine. Active code.

Each of the three levels is auditable on its own.

An auditor can read the vocabulary without understanding logic.
He can follow the permitted processes without reading a single line of code.
And he can test the calculation in isolation without knowing the vocabulary.

If you were to put the threshold values or the processes into the ontology, this separation becomes blurred, and a technical auditor steps in, because vocabulary, permission, and calculation can no longer be accounted for separately.

The workflow, step by step

Step 1: The portfolio manager requests the report

Portfolio manager: “Create the quarterly report for portfolio green fund”

The LLM interprets the user’s text.

Step 2: The ontology checks whether the data is valid

Before anything happens, it is checked whether the raw data is complete.

PortfolioShape
  sh:property [ sh:path :consistsOf        ; sh:minCount 1 ] ;   # at least 1 asset
  sh:property [ sh:path :co2IntensityScore ; sh:minCount 1 ] .   # every asset needs the value

If an asset is missing the CO2 value, it aborts here. The language model never receives incomplete data.

Step 3: The deterministic layer calculates and decides on sections

The rule engine calculates the metric and checks the threshold values. This logic is not in the ontology.

waci = calculate_weighted_co2_intensity(data)   # e.g. 205
 
sections = ["Summary", "Performance"]
if waci > 200:
    sections.append("Carbon Mitigation")         # rule applies, 205 > 200

The result is a fixed set of facts:

facts = {
    "waci": 205,
    "loss_percent": 12.4,
    "triggered_sections": ["Carbon Mitigation"]
}

Step 4: The facts are sealed

A fingerprint is placed over the calculated facts and the rule set used:

"files": {
  "facts":         "sha256:0dd41a5e76067a1d33945859e13c582cacff713dd...",
  "decision_space": "sha256:5c226b4a254ea6e688eb155b5dbb62c29cbe496c..."
}

Important: The seal proves integrity, not correctness. It guarantees that nobody has changed the numbers after the calculation and that anyone can recalculate exactly, from which data under which rules. It does not claim that 205 is the absolutely correct number.

Step 5: The controlled process up to the text

Nothing runs through in one step. There are fixed stations with guards:

{
  "id": "validate_report_build",
  "from_state": "ingress",
  "to_state": "validated",
  "guard_refs": ["guard:payload_valid"]
},
{
  "id": "execute_report_build",
  "from_state": "validated",
  "to_state": "executed",
  "guard_refs": ["guard:facts_sealed"]
}

from ingress only into the validated state if the data is valid
from the validated state only further if the facts are sealed.

Step 6: Only now the language model, and it may not write a single number

The guarantee is that the deterministic layer inserts the numbers itself, so that the model physically does not write the number at all.

The model works with placeholders:

# The model delivers text WITH placeholders, not with numbers:
#   "The portfolio recorded a loss of {loss_percent}%."
 
report = insert_sealed_numbers(model_text, facts)
# The deterministic lane fills {loss_percent} with the sealed 12.4

If the surrounding prose drifts anyway, fail closed applies: The system reports it and generates anew under stricter specifications, instead of silently rewriting.

Explanation:

Numbers: Here there is no drift at all that would have to be detected, because the model never writes the number. The model delivers {loss_percent}%, the code inserts the sealed 12.4. It is physically impossible that a different number stands there.

Formulation of the prose: Example: The model writes “a slight decline of 12.4%”. The number is correct, but the word “slight” contradicts what 12.4% means. Code recognizes this only via predefined rules, for example: a loss over 10% may not be described with mitigating words from a blocklist.

What does fail closed mean in practice?

There is no second AI that reads and understands the text and then passes judgment.

It is a deterministic check step, that is blunt code, that compares two things:

the sealed facts
and the text delivered by the model.

Who sees the drift: a piece of check code that runs after text generation.

Who says fail closed: the same function.

If the check fails, it does not output the text, but restarts generation with stricter specifications.

Step 7: The limit of the guarantee

With numbers the system is watertight.

Qualitative statements like “in line with climate goals” are softer, that remains an opinion.

Whether these formulations are successful and defensible is checked by the portfolio manager at the end.

This check is, however, pleasant and comprehensible for him with this approach, because every number in the report is backed by its sealed proof and its source.

The robust facts therefore lie openly alongside, and the human decides on this basis about the classification.

The portfolio manager can therefore bring in his experience and his knowledge, and thus this approach increases not only the value of the prefabricated draft but also the value of the employee himself.

Difference to the autonomous AI agent

What is the difference between this approach and a freely acting autonomous AI agent?

Autonomous AI agent

The agent is the actor. The human delegates a task to the agent and gives it a goal. The receiving agent explores its own capabilities at runtime and dynamically decides what it does.

This approach here

Exactly this part, the dynamic capability discovery as primary control, is taken out.

The reasoning are the failure modes that it produces: invented capabilities, overreach onto unwanted tools, non-deterministic tool chains, weak traceability (why did it do that?).

What this approach keeps

The agent becomes a bounded execution surface.

Within the defined frame, something like planning and selecting may still happen.

Which permitted action is executed in which order remains a decision, only limited to a pre-signed function space.

The actual difference in philosophy

Autonomy (how much the system decides itself): Here this approach is indeed still capable of deciding, within the boundary.

Closed-world as action space (where the permitted actions come from): Everything outside the action space is structurally not executable. Here this approach is the real opposite, closed instead of open, bound in advance instead of discovered at runtime.

Plumber example

The principle can be shown with a simple example.

Customer: “I have a leak”

The system does not do: openly negotiate over all possible plumber tools, freely run a capability search across multiple agents.

The system does: load the plumber pack, assign the word “leak” to an intent cluster, release only the permitted actions.

allowed actions:
  - diagnose      
  - isolate       
  - repair        
  - escalate

Which of these four actions in which order, that remains a decision.

But the agent cannot suddenly send an invoice or delete appointments, because these functions simply do not exist in the permitted function space. Exactly that is the difference: not less intelligence, but a boundary drawn in advance and signed.

What that means for a regulated environment

Useful agentic behavior is preserved.

The liability and audit problems of the open tool space disappear!

As a side effect, resilience against prompt injection arises: Injected text can propose actions, but cannot extend the permitted function space.

In one sentence: It is not a renunciation of agents, but an agent in a pre-signed frame. Closed action space instead of open self-service.

My personal conclusion

I find this approach brilliant. It corresponds to my worldview, my way of thinking, my understanding of AI.

This way and no other is how I want to deploy AI, and exactly this way is how I want to work.

It may of course be that over the course of time, the more one learns and the faster the technology advances, details may change.

But I am pretty sure that the underlying principles are timeless and therefore right. I am also pretty sure that I will not completely change my fundamental attitude to life.

What is your personal conclusion after reading this article?

Discuss with me! Opposing opinions warmly welcome!

Outlook

Maybe you already sense it. If you take this approach and lay this philosophy as the foundation, a different operating model results from it later:

Employees are no longer forced to codify their knowledge
or to make themselves redundant.
Employees gain a higher status than before.
Employees do not monitor AI agents,
but rather employees bring in their experience and their knowledge to raise the preliminary work of the AI to the value of the company.

From this, different organizational structures result than with another architecture model.

You may see:

People with business knowledge must also understand this! An ontology can only be created with business knowledge!
Maybe it is exhausting at first to read articles like these, but it is worth it, because this way you can actively help shape the AI transformation!

You want more of this?

You know someone who is interested in this?

Share Bianca J. Schulz