Where we work
We work where the consequences are real: sectors in which regulation, integration depth and the cost of a wrong answer decide how systems must be engineered.
Sector experience gets claimed loosely. The useful version of it is narrow: knowing what a system has to survive in your sector before anyone will let it run, which review it faces, which system of record it is not allowed to disturb, what its data is not permitted to do, and what a reviewer will accept as evidence that an answer was right. The five pages below set that out sector by sector, in the language your own risk, security and operations people already use. Where our standing in a sector rests on systems the founders built themselves, the page says so.
-
Banks, payments, insurance and fintech
We build AI systems that can survive an audit: decision systems, retrieval over regulated documents, and the controls around both. The founders designed payments infrastructure where every payment is bound to an auditable spend policy, and built security tooling that reports against SOC 2, ISO 27001 and PCI-DSS. That is the discipline we bring to banks, insurers and fintechs.
Financial services in detail →
-
OEMs, suppliers, mobility and retail
Automotive AI lives inside an estate of existing systems: ERP, dealer platforms, telematics and supplier data. We build the integration layer and the AI on top of it, from copilots for sales and service operations to decision systems over vehicle and warranty data. Every build is engineered for the systems already in place, not for a clean-room demo.
Automotive in detail →
-
Manufacturing, logistics, ports and infrastructure
Manufacturing and logistics generate operational data that rarely reaches the systems that could act on it. We build the pipelines that move that data and the AI systems that use it: monitoring, scheduling and decision support connected to the platforms already running the operation. The founders built and operate an attack-surface management platform, so exposure assessment is part of how we design for industrial estates, not an add-on.
Industrial in detail →
-
Providers, life sciences and health platforms
The founders built and operate a clinical operations platform for behavioural-therapy practices in the United States: regulated clinical data, scheduling, billing and family communication, with strict per-practice data isolation. That platform sets the bar for our healthcare work, where interoperability standards and HIPAA obligations are design inputs from the first architecture. We build AI systems for providers, life sciences and health platforms to the same standard.
Healthcare in detail →
-
Large organizations with complex software estates
Large organizations rarely need another point tool; they need AI that works inside the identity, ERP, CRM and data platforms they already run. We design for that estate first, then build the system: agents, retrieval and workflow automation, with evaluation, security review and observability in the architecture rather than added later. Handover is part of every build, so your team operates what it owns.
Enterprise technology in detail →
Why five sectors and not a longer list
A long sector list is a marketing artifact. It signals coverage, and coverage is not something a firm this size can honestly claim. These five are here because the engineering discipline behind them is evidenced rather than asserted: regulated clinical operations, payments bound to an auditable spend policy, security tooling that reports against SOC 2, ISO 27001, HIPAA and PCI-DSS, live network and security operations, and estates where AI has to work among systems bought long before anyone in the building said the word model. The list stops where that evidence stops. We would rather name five sectors we can be questioned about than a longer list we cannot, and we would rather decline a sector in the first conversation than learn what it demands at a client's expense.
What carries across all five
Most of the engineering underneath these five is common to all of them, which is the honest reason a firm this size can work across them. Regulated data behaves the same way whether it is clinical, financial or industrial: it has a residency, a boundary it must not cross, and an entitlement question attached to every retrieval. Integration is the same problem too. In every one of these sectors the AI arrives late, into an estate that predates it and keeps its own controls, so the real design question is what the new system may write and what it may only propose. And every one of them ends in a review. The forms differ; the demand does not. Show what the system decided, on what basis, and who approved it.
What a sector page is, and what it is not
Each page below states what we design for in that sector: the reviews a system has to pass, the platforms it has to live among, and the evidence its owners will be asked to produce. That is what those pages are. They are not a staffed sector practice. Caltor has no vertical with its own leadership and its own bench; the same partners and the same engineers work across all five, which is another reason the list is short. They are also not a client roster. There are no client names, no case studies and no client logos on this site. Where we point at proof, it is a system the founders designed, built and still run themselves, and the page says so in those words.
Talk to a partner
If your problem has those properties but none of these five labels, describe it anyway. A founding partner reads it and tells you whether this is work we should take, including when the answer is no.
