Insights

Practical thinking on AI that has to work on Monday.

Short, honest pieces from the engineering side of agentic AI, written for the people who have to run these systems, not sell them.

Agentic AI · 8 min read

Why most AI agents never leave the demo

A demo needs one happy path. A production agent needs to survive the other 95 percent: missing data, a tool that times out, an ambiguous request, a policy that says "not this customer". The gap between the two is not a smarter model, it is testing, evaluation, permissions and the boring integration work nobody puts in the pitch.

Our rule of thumb: if you cannot list the ten ways the agent should stop, it is not ready. Evaluation suites with edge cases and adversarial inputs, scoped tool permissions, an approval step for consequential actions, and a trace for every outcome turn a demo into something an operations team will actually trust.

Talk to us about your pilot

Engineering · 6 min read

AI-generated tests are only useful if you can trace them

Inside a regulated Austrian operator we built a platform that analyses Java code changes and generates JUnit tests. The clever part was never the generation. It was the hash-based traceability: every generated test is tied to the exact code change, the queued job that produced it and the review that accepted it. When an auditor asks "why does this test exist?", there is an answer.

The lesson carries to every agent we build: outputs without provenance are technical debt with a nicer interface.

Strategy · 5 min read

The EU AI Act for mid-sized companies, on one page

Most business-process agents, drafting replies, extracting data from documents, triaging requests, fall into the limited- or minimal-risk categories. What that means in practice: be transparent that people are interacting with AI, document what the system does and what data it uses, keep a human able to intervene, and classify the use case once. High-risk obligations apply to specific domains (employment decisions, credit, critical infrastructure), if you are there, you will know.

We classify every use case in the discovery phase and hand over the documentation, so compliance is a by-product of building, not a separate project.

Design · 7 min read

Designing the human-in-the-loop so people actually use it

An approval step that interrupts someone forty times a day gets rubber-stamped by day three. Good human-in-the-loop design is about where the checkpoint sits (before the consequential action, not before every step), what the person sees (evidence and the proposed action, not a wall of reasoning) and how the exception is routed (to the person who can decide, with a deadline). Get those three right and the checkpoint becomes the moment your team trusts the system most.

Featured · Checklist

From pilot to production: the twelve questions

  • What exactly is the agent allowed to do, and with which tools?
  • Which actions need a human before they happen?
  • How do we know it did the task right? (Evaluation set, not vibes.)
  • What happens when a tool fails, data is missing or confidence is low?
  • Where does it read from, and is that access permission-scoped?
  • What is logged, and could we reconstruct any outcome from it?
  • What does one run cost, and what is the monthly budget?
  • Who owns the agent after go-live, and who gets paged?
  • How is a bad answer reported and fixed?
  • Which model, and what is the fallback when it changes?
  • How is it documented for the AI Act and for the next engineer?
  • What would make us switch it off?

Want the checklist applied to your process?

Book a free call