DocsSign inInstall Kastel
Careers

Giving companies back the ownershipof their intelligence.

Kastel isn’t an AI. It is the fortress that holds a company’s knowledge and gives it structure, and where every AI you plug in sees only what you allow it to see. We are building that layer for Europe’s regulated organisations, and we are looking for three engineers in Paris to take it much further.

See the rolesWrite directly
01

What is already built.

This is not an intention, it runs. The engine absorbs a company’s sources, derives its organisation and answers questions about it; the managed hosting provisions isolated instances in Europe; the audit chain keeps a record of what was written and approved. There is an enormous amount left to deepen, and that is exactly the work.

The context engine

It runs the interview with the company, reads its documents, works out how the organisation is put together and how it operates, then publishes all of it over MCP, the standard socket AI tools plug into.

55 connectors already wired

The engine can read a mailbox, a CRM, a project management tool, a payroll or an e-signature system. We recount them in the code before every publication.

Hosting in Europe

Every managed client gets its own instance, isolated from the others, on Kubernetes. No client shares an engine with another, and that is an architectural constraint before it is an argument.

The audit chain

Every write carries its author, every approval leaves a trace, and the whole thing stays verifiable months later, the day an auditor asks for it.

The delivery log
02

The open roles.

Each role covers a part of the product nobody is looking after today. You would be the first person responsible for it, with the freedom and the weight that implies.

Context engine engineer

Understanding a company from its documents, in the mess they come in, is the central problem of the product and it is far from solved. You would work on the interview that builds that context in a single session, on the retrieval chain that draws from it, and on the evaluations that tell you whether a change actually improved anything. In Python, on Postgres.

What you need to be able to do
  • You have shipped a system that searches documents to production, and you remember what went wrong in it.
  • You know what it takes to read a crooked scanned PDF or a ten-year-old mailbox, and it does not put you off.
  • You can build an evaluation that tells a real improvement apart from an impression.

Platform and security engineer

We host isolated instances in Europe for clients who have a security officer and auditors. You would own that entirely, from provisioning to secrets, from encryption to the restores you have to test long before you need them. You would also answer the security questionnaires that come with every client, and every awkward answer would turn into a fix in the product.

What you need to be able to do
  • You have run Kubernetes in production, with the on-call that comes with it.
  • You can write a restrictive network policy, and above all explain why each exception is in it.
  • You have already had an auditor sitting across from you.

Engineer deployed at client sites

The product learns nothing more inside our offices. You would install it in regulated organisations, map with them who decides what and who is allowed to see what, connect their sources exactly as they are, and come back with the list of everything that resisted. That list is the raw material of the product.

What you need to be able to do
  • You write Python and you are comfortable in front of an IT department.
  • A real client’s mess interests you more than it annoys you.
  • You are willing to spend weeks on client sites, in France.
The terms, identical for all
  • A full-time permanent contract, open now.
  • In Paris, in our offices.
  • Pay is in line with the senior Paris market, and we discuss it in the first conversation.
  • A CV is not required. Tell us what you have built instead.
03

How we work.

A few ways of working that you cannot guess from the outside.

A founding team, small for a long time

Today there is the founder and AI agents writing a large share of the code. Tomorrow, a few engineers each owning a whole part of the product, and staying few by choice.

Machines do the repetitive work

A good part of the code is written by agents, every day. What we expect from you is judgement: deciding what is right, checking what was produced, and refusing what does not hold.

Decisions get written down

Every product call is recorded and dated, with the reason that won. You would be able to read why something was decided two months before you arrived, instead of rediscovering it by accident.

04

Hiring.

The process is short, and it is the same person from start to finish.

1

An email

Write to jobs@kastel.ai and tell us what you have built. A link to something real beats a cover letter.

2

A conversation

An hour with the founder, about the product, about the role, and about what you would want to do with it.

3

A real problem

We take an actual problem from the product and look at it together. That is the only exercise, and it looks like the work you would be doing.

Every application gets an answer, and the decision comes in under two weeks.

The missing role might be yours.

The team will stay small, so every role carries weight. If none of these fits you but the project speaks to you, write to us and say which one you would create.

Propose a roleRead the manifesto