Executive synthesis
Current founder direction, 24 October: prioritise C-level understanding through mechanisms, trade-offs and decisions. No measured own-work case is required and no case outcome may be fabricated. Follow the current direction [local reference omitted].
Decision-ready research for the Knauf Digital Tech Leadership Visit, 29 October 2026. Evidence checked 22 October. This is the synthesis to use when workstream memos offer several examples or optional approaches.
Recommended argument
AI cost optimisation means delivering an accepted business result at an appropriate total cost. The right intervention depends on the workload, its constraints and the value of the engineering effort.
The session should leave leaders able to ask five concrete questions:
- What accepted work did the spend buy?
- Which part of the workflow creates the cost?
- Which requirements must an alternative preserve?
- How much cost can actually be removed or useful capacity released?
- Does the improvement justify implementation and continued operation?
These questions connect financial governance to the speakers’ technical expertise. They complement the agenda’s preceding value session and following cost-reduction case.
Findings that change the presentation
| Finding | Evidence status | Implication |
|---|---|---|
| Knauf Digital publicly works across commercial digital services, product information and customer workflows | Official company sources, K01–K05 | Use product-data enrichment as an illustrative main case, then contrast interactive technical-information retrieval |
| Resource metrics and business metrics answer different questions | Primary FinOps guidance, G03 | Explain tokens briefly, then move to cost per accepted result |
| Costs extend beyond a model request | Production architecture guidance, C10/C12, plus accounting synthesis | Include SaaS, tools, data services, infrastructure and human work in the cost map |
| Batch discounts and cache reuse have eligibility conditions | Current official API/runtime documentation, C04/C05/C07 and O04–O06 | Show when an option fits rather than a universal percentage |
| A finance budget alert may arrive after consumption | Azure/AWS official behavior, G07/G08 | Distinguish the monthly funding envelope from limits on an agent run |
| Self-hosting economics depend on qualified demand and operating obligations | Official hosting guidance plus transparent analyst model, C11/C12 | Keep the hosting decision conditional, with demand and service requirements explicit |
| Savings and released staff capacity are different benefit classes | Accounting synthesis consistent with G14 | Keep invoice savings and economic-capacity scenarios separate |
| Optimisation itself consumes engineering resources | FinOps guidance and simple arithmetic, G14 | End with a conservative payback decision and a small pilot |
Audience and setting
The agenda places this talk after lunch, within financial governance. The audience has already heard about sourcing and governance, and is about to hear a particular 90% reduction case. Repetition would weaken the contribution.
A useful talk therefore alternates between business questions and visible engineering consequences. Avoid a long founder story, a provider catalogue or deep GPU internals. Start with a one-minute introduction to both speakers and their work on efficient inference. Explain both the economic/evaluation framing and how engineering changes resource consumption. Assign delivery roles only after content and visual design are final; keep handover cues unassigned.
Public evidence does not identify the visitors’ stack, spend, maturity or exact priorities. Treat all proposed Knauf workflows as hypotheses. A job advertisement establishes relevant work, not a diagnosed operational problem. Public company and partner case studies cannot provide model-cost data.
The financial-model review [local reference omitted] extends this synthesis into readable formulas for business contribution, complete costs, portfolio aggregation, constrained choices, budget reservations and investment cash flows. Show selected relationships through their decisions; do not imply an approved Halbach tariff or a deployed mathematical optimiser. Both founders’ mathematics backgrounds belong in the brief introduction, supported by the company record.
The cost model to teach
For a specified period and workload:
Cost per accepted result = total attributable service cost / results meeting the agreed acceptance rule and service requirement.
Runtime cost includes all attempts, tools and retries. Attributed review and shared platform costs must use a consistent policy. A lifecycle decision also needs implementation, evaluation, transition and continued maintenance over an explicit horizon.
Keep three questions separate:
- Marginal cost: what changes when one more task runs?
- Avoidable cost: what disappears if this workflow or architecture changes?
- Fully loaded cost: what resources sustain the service?
Do not mix these views inside a before/after comparison. Show shared cost openly. An internal allocation can change while the company’s invoice stays the same.
A diagnostic issue tree
The following is a proposed analytical tool, not a statistical claim about enterprise cost shares.
| Driver | What to measure | Possible response |
|---|---|---|
| More useful demand | Accepted task volume, adoption, task mix | Scale if unit economics and business value justify it |
| More work per task | Calls, retries, context, generated output, tools | Remove repeated work, simplify, control agent loops |
| Mismatch between task and model | Acceptance, errors, review by task class | Test a smaller model, bounded task or escalation policy |
| Repeated computation | Changed inputs, cache reads/writes, warm-up | Reuse eligible work with version and access controls |
| Inefficient paid capacity | Useful throughput, traffic peaks, idle paid time | Tune scheduling, right-size or reconsider hosting |
| Excess human work | Review/correction minutes, escalations, rejected cases | Improve data/workflow quality rather than only usage rates |
| Poor contractual fit | Seats, credits, commitments, actual usage | Review adoption, procurement and renewal choices |
More total spending can be rational when more accepted work creates enough value. A lower invoice can be a bad result if useful work or quality falls.
Evidence for the optimisation options
The recommended investigation order is to understand the service contract, inspect expensive steps, test low-effort reversible changes, then consider deeper model/runtime or hosting work. This is a heuristic. Measured bottlenecks can justify a different order.
- A deterministic operation may avoid an unnecessary model call.
- Better task scope, shorter useful outputs and fewer redundant calls can reduce work.
- Model selection and routing require domain evaluation and a credible fallback.
- Prefix caching, completed-result caching and warm services reuse different things.
- Asynchronous batch processing fits jobs that can wait. Online batching must respect latency.
- Fine-tuning, distillation, quantisation and custom kernels can be worthwhile at sufficient scale or for a binding constraint, with full lifecycle cost included.
- API, managed dedicated capacity and self-hosted deployments should be compared on the same acceptance, service and operational requirements.
Do not put every technique on stage. The optimisation matrix is the research inventory. Main-stage material should show a few choices applied to the main workflow.
Example selection
Use a concrete product-information operation to explain decisions qualitatively. The consolidated product-data calculations remain labelled synthetic workpapers, not measured outcomes or a required numerical case. Do not create a fictional success story from them.
The governance memo’s smaller two-column cohort and the cost memo’s isolated token calculation are alternate explanatory workpapers. They are not additional Knauf cases and should not all appear in the same talk.
The earlier recommendation to use the internal selective-cache / quality-rejection case is superseded. Retain that evidence for research, but do not require or restore it to demonstrate presentation depth. Explain the quality, resource and financial trade-off at leadership level without inventing a replacement case.
Prioritisation rule
First exclude changes that fail critical quality, latency, data-handling or availability requirements. For feasible changes, calculate conservative avoidable benefit over the workload’s realistic lifetime, less implementation/evaluation/transition and added operation costs.
Use a range rather than an invented confidence score. Check volume, review effort, attainable change, useful lifetime and whether cost is genuinely cancellable. Consider reversibility and time to benefit.
The worked example has an eight-month runtime-cash payback under its assumptions. Counting every released review hour gives a much faster economic-capacity payback, but it does not establish cash savings. A short-lived workload may not justify a deep migration.
Keep the savings-ceiling argument, but frame its main-stage relevance at annual enterprise portfolio/service and rollout scale. The earlier €300/month calculation is a small-scale teaching workpaper, not the financial anchor for this audience. Do not invent a larger spend or attainable reduction to make the argument impressive. Use sourced scoped amounts, explicit conditional arithmetic or qualitative relationships.
Practical close
Propose one 30-day pilot, rather than a company-wide optimisation programme:
- Choose one material recurring workflow and name the business, technical and finance owners.
- Define acceptance, latency, the cost boundary and benefit classification.
- Establish a representative baseline and reconcile the major costs.
- Test one or two reversible changes with rollback and runtime controls.
- Decide whether to scale, optimise further, redesign, hold for evidence or stop.
The deliverable is a defensible decision. A lower invoice is one possible result; justified scaling can also be right.
Explain what follows a successful test: apply the change within the agreed authority, monitor cost and quality, and reassess when task mix, demand, models, prices or service requirements change. Include the effort of this continuing optimisation. Distinguish a general operating method, capabilities currently available and Halbach’s product direction; do not imply the full loop is already deployed.
Critical unknowns and research limits
There is no internal Knauf usage, architecture, contract, outcome-quality or review-time dataset. There is no basis for a Knauf savings estimate, model recommendation or hosting verdict.
Official pricing and product documentation are mutable. The preserved rate CSV is a dated snapshot, not a quote. Standards and telemetry have version/support limits. Partner stories are attributed claims. Internal prototypes have narrow measurement boundaries. Research breadth is substantial, but this is a targeted decision dossier rather than a systematic literature review or customer discovery study.
Before writing the final spoken script, the highest-value new information is one approved Knauf workflow with approximate volume, required quality, response time and review effort. The present outline remains usable with the clearly labelled illustrative case.