Interview with Iacob Marian from QPillars

About QPillars

QPillars is a Zurich-based startup, supported by Innosuisse. We build the infrastructure that lets AI agents operate laboratory instruments reliably and safely.

SiLA: What specifically motivated you to add SiLA to your product?

We came to SiLA from an unusual direction. Not as an instrument vendor needing connectivity, but from the AI-agent side. We were building the infrastructure to let agents drive real lab work, and kept hitting the same wall: an agent is only ever as good as the interface it acts through. You cannot build a repeatable recipe on a foundation you redefine for every instrument. We needed a standard to stand on, and the moment we found SiLA 2, a large part of the problem we had been wrestling with was already solved.

SiLA: How did you find the experience of integrating (the code base, the community, total effort etc)?

Better than we expected, honestly. The specification is coherent: features, typed commands, properties, and defined execution errors. It is the kind of model you wish more domains had. The tooling quickly took us from a feature definition to a running server and client. The remaining effort involved some minor adjustments: proper data plumbing, ensuring correct error semantics, and making the whole thing robust enough for an autonomous system to depend on it. The community was approachable, and we got great feedback and support from its members.

SiLA: What would you say to anyone considering using SiLA?

Do it, and adopt the model fully rather than treating it as a thin wrapper. The payoff is not just connectivity; it is that the interface becomes something both people and software can reason about. Modeling an instrument properly pays for itself the first time a second piece of software needs to communicate with it without a custom integration. And if you have any ambition to put automation or AI on top, a standard interface is not a nice-to-have, it is the precondition.

SiLA: Finally, is there anything SiLA could do better?

Only one thing comes to mind now. SiLA’s type system is genuinely strong – structures, enumerations, ranges, schema-constrained values – but many interfaces rely on plain strings where the value is actually an enum variant. So the one thing we would value is a linter for feature definitions, similar to clang-tidy or rust clippy, that flags weak spots and suggests the stronger SiLA type for each. Ideally that check should live inside the official code-generation and validation tools, so it runs where authors already work and reports simple typing warnings. None of it requires a change to the standard – the expressive power is already there – it just matters more as the consumers of these interfaces become software rather than people.

Looking forward – how will SiLA 2 support the agentic way of working?

This is the part we care about most. We think SiLA 2 is unusually well-positioned for the shift to AI Agents. Agents need exactly what SiLA already provides: a typed, discoverable, self-describing interface to the physical world. An agent that faces a different bespoke API for every instrument cannot be made reliable; an agent that meets every instrument through one standard can. That makes SiLA the substrate on which lab agents become trustworthy – the place where capabilities are described, actions are validated, and failures can be reasoned about consistently. Our bet is that the labs adopting a standard like SiLA now will be the ones that can safely put agents to work first. The open questions – how agents discover capabilities, how much semantic context an interface should carry, how to verify an action before it reaches real hardware – are exactly where we think the next round of standardization should go, and we would gladly help push it there.