Skip to content
Back

FAQ

The opening question

My first conversation starts with a question, a different one for each use case. The answer shows which of the five building blocks applies, and sometimes that none of them does. I say that too. The answers fall into three groups: the core of my approach, my approach with an honest limit, and listening before solving. Below, for each case, the question, the answers I hear, and what I do with them.

Accounting

Where does most of the rework arise today between a document coming in and a finished booking?

Answer

  1. The coding is often wrong because the document alone does not say which contract or which policy applies.

    What it means for my approach: That is the core of building block 1. The RAG pipeline reads the document and, in the same step, checks it against policies, contracts and tax rules. The agent argues from the source, and the coding gets the context it lacks today.

    The limit: Whatever lives only in people's heads is written down first; otherwise the agent has no source to argue from.

  2. Most of it is routine, but every booking passes through the same two pairs of hands.

    What it means for my approach: Building block 2: the whitelist. Documents up to a fixed limit are booked automatically; anything above it and anything unusual goes to the gate. The two pairs of hands then check the exceptions instead of the bulk.

  3. At year end the auditor asks questions, and we have to reconstruct who booked what and why.

    What it means for my approach: Building block 3: the hash-chained audit trail. Which document was read, which prompt ran, which person approved: all of it sits immutably in the log. The reconstruction falls away; the path to the booking is already there.

  4. We already had a tool. After an update it got worse, and we only noticed months later.

    What it means for my approach: Building block 4: golden sets. Every model change and every prompt change is measured against real, correctly coded, anonymised data before it goes live. A drop in quality shows up in the measurement, not in the year-end close.

  5. Our accountants do not want this. They fear losing control over errors.

    What it means for my approach: Building block 5. The system stops at precisely defined gates: a discrepancy in the cash discount, an unclear cost centre, a new supplier. There the person decides, and the correction flows back in a structured way. Autonomy grows with proven quality, at the pace the specialists are willing to carry.

  6. Documents arrive late and incomplete from the business units.

    What it means for my approach: That is waiting. An agent does not make a document arrive on time. My approach starts once the document is there.

    The limit: My approach does not help here: the bottleneck sits upstream of accounting, in the business units.

The second question: And how much of that is waiting for documents and approvals, and how much is correcting bookings?

In one sentence
In your setup the agent does more than read the document. It checks it against the stored policies, contracts and tax rules, by RAG, with the source. A whitelist in front, so only routine is booked automatically, a hash-chained trail behind, so every booking can be evidenced to the auditor. Result: less rework, and the books stay documented for audit.

Agentic processes at work: the accounting example →

Tax advisory

Where is most of the time lost today between the client's documents and the licensed adviser's signature?

Answer

  1. Looking things up. Every assessment has to be checked against the current state of the law: statute, administrative guidance, case law.

    What it means for my approach: Building block 1: RAG for the current law. The agent checks the facts of the case against the stored state of the law and the firm's work instructions, and delivers source and date with it. The licensed adviser reads the draft with its evidence instead of searching for the evidence personally.

    The limit: The stored state of the law has to be maintained; otherwise the agent has no source it is allowed to argue from.

  2. Standard cases eat the time we would need for tax planning questions.

    What it means for my approach: Building block 2: the whitelist. Standard cases with no room for judgement are prepared automatically (drafts, deadline overviews, follow-up questions to clients); anything involving discretion goes to the gate. The agent never files anything. The licensed adviser gets the time back for the cases that involve judgement.

  3. When a client or the liability insurer asks, we have to reconstruct why we decided the way we did.

    What it means for my approach: Building block 3: the hash-chained audit trail. Which state of the law applied, which source was read, which licensed adviser approved: all of it sits immutably in the log. In a liability question, the path to the decision is fully traceable.

  4. We tried an AI tool. At some point wrong drafts came in series, and nobody knew since when.

    What it means for my approach: Building block 4: golden sets. Closed, anonymised cases with a known correct outcome are the yardstick. Every model change and every prompt change is measured against them before it goes live. The "since when" then has a date.

  5. Our licensed advisers do not want a machine making decisions.

    What it means for my approach: With me that is the design, not a concession. The system stops at precisely defined gates: tax planning questions, unusual facts, a strong deviation from the previous year. There the licensed adviser decides. Reserved professional tasks stay where they belong.

  6. Clients deliver late. The deadline pressure starts before the firm.

    What it means for my approach: That is waiting. The agent can prepare deadline overviews and follow-up questions to clients, so the firm chases earlier and more precisely. Delivering is still up to the client.

    The limit: My approach has no influence on when the client delivers; it only helps at the firm's own desk.

  7. Our bottleneck is staff. We cannot find licensed advisers.

    What it means for my approach: My approach takes preparation off the licensed advisers you have and gives them time back. It does not replace one.

    The limit: Reserved professional tasks cannot be delegated to an agent; if the licensed adviser is missing, they are missing with an agent too.

The second question: And how much of that is waiting for the client, and how much is preparation the licensed adviser does personally?

In one sentence
The agent prepares, the licensed adviser decides. In between: check the facts of the case against the stored state of the law, by RAG, with source and date. A whitelist in front, so the agent prepares drafts, deadlines and follow-up questions and nothing else, a hash-chained trail behind, so every decision can be reconstructed in a liability question. Result: more of the licensed adviser's time for tax planning, with responsibility unchanged.

Agentic processes at work: the tax firm example →

Gaming

Where do you lose the most time today between a finished game and going live in a new market?

Answer

  1. Certification takes long. The test lab needs weeks.

    What it means for my approach: I do not make the lab's turnaround any faster, and I say so openly. The time is lost in the loops: the submission comes back, gets fixed, goes in again. Building block 1 checks the release candidate against the stored market requirements before submission, and the audit trail from building block 3 produces the documentation package for the lab as a by-product.

    The limit: I do not make the lab faster. But I make sure you only go there once.

  2. Every market has different requirements, and the knowledge about them sits in two or three heads.

    What it means for my approach: That is the core use case. Building block 1 stores the requirements per jurisdiction and checks with a source instead of from memory. The knowledge moves from heads into the pipeline: it scales to new markets and survives staff turnover. The bottleneck here is knowledge, not speed, and that can be solved without anyone having to work faster.

  3. The test matrix explodes: game × market × platform.

    What it means for my approach: Building block 4: golden sets. Agents generate and run the market-variant tests against fixed reference cases; the certified mathematics stays untouched. QA then no longer grows linearly with the number of markets.

  4. Operator and platform integrations eat the time.

    What it means for my approach: Building block 2: the whitelist. The agent prepares release packages and configurations per operator and flags deviations; every new integration is a gate (building block 5). The person checks the deviations instead of everything.

    The limit: If the bottleneck sits with the operator (their staging, their priorities), the approach only helps on your side of the interface.

  5. Internal approvals drag on. Nobody wants to tick the box.

    What it means for my approach: That is an organisational problem, not a technical one. My answer: precisely defined gates instead of diffuse responsibility (building block 5), and the hash-chained trail (building block 3) that makes every approval defensible. Whoever approves can show what was checked against. People sign faster when they are not personally exposed. Structure instead of appeals.

  6. We are waiting for licences and regulatory decisions.

    What it means for my approach: My approach does not help here; that is a legal matter. My counter-question: what do you do with the waiting time? Prepare the markets technically so you can go live on the day the licence arrives. Release on demand.

    The limit: No agent speeds up the regulator's decision.

  7. We hardly lose any time. Our bottleneck is content: new games, assets, localisation.

    What it means for my approach: Then I do not force the model onto the release process. The same guard rails (whitelist, golden sets, gates) carry in production too: localisation, asset variants and promo configurations handled by agents, the certified core left untouched.

The second question: And how much of that is waiting, and how much is rework?

In one sentence
I would not put agents into your game but around it: check the release candidate against the stored market requirements (by RAG, with the source), a whitelist in front so nothing certified is touched, a hash-chained trail behind so every release decision can be evidenced to the test lab and the regulator. Result: faster market entries with the certification status unchanged. That is release on demand for a regulated portfolio.

Agentic processes at work: the game development example →

Two rules for the conversation

  • Not every answer gets my model as the reply

    Some answers describe a problem my building blocks do not solve: legal questions, waiting on third parties, missing staff. Then I say so. In the conversation that is often the strongest answer, because it makes the other answers credible.

  • Second question first, then the solution

    After the first answer I ask: how much of that is waiting, and how much is rework? The two have different solutions. Whoever does not separate them builds at the wrong end.

Rules and limits →