Contents · 10 sections
The Role
01 — Principal Founding Engineer
Agentic Finance · UK, Luxembourg, Portugal, Spain, Remote-EU · Reporting to Founder
Principal Founding Engineer, Agent Systems
Noumenai builds AI that does real finance work. Not summarisation. Not a copilot that drafts something a person then rewrites. Agents that go into a financial system, take a position on what a transaction is and — when the evidence and the confidence justify it — post it. Ledger, reconciliations, close, tax. The work that was always done by people because the cost of being wrong was too high to automate.
That cost hasn't gone away. The models are what finally got good enough to make it worth engineering around it. That engineering — not the model — is the company.
The name comes from the noumenon: the thing as it actually is, behind the appearance. The number that looks right and the number that is right don't always coincide. Everything we build exists to close that gap.
Ten sections. Read the ones that matter to you.
The Role
02 — What you'd do
You're a founding engineer and not an extra pair of hands.
Writing code is no longer the scarce resource. Judgment is.
You'll be given problems, not tickets. You decide how to solve them, drive an agent to build most of it, prove it against production systems and come back with something integrated. And you'll be one of the people in the company with the standing to say: no, this isn't proven yet.
In Production
03 — We are not an idea
There is product in production.
Today, in a client's real accounting, with a live write path into an ERP — reviewer, confidence gates, audit trail. Built in a matter of months.
There are enterprise clients in the pipeline, and the incubation of a joint venture with a multinational group.
The Domain
04 — What this domain actually demands
Agentic finance is not a normal software problem.
Most excellent engineers aren't automatically good at it. Four things make the difference.
01
The failure mode is being confidently wrong.
A model produces a plausible number for anything. Accounting is full of numbers that look right. Our discipline is that the model never originates a value — it chooses the method and explains itself, and deterministic code produces the number. You need to feel why that boundary exists, not treat it as a rule someone handed you.
02
Some actions can't be undone.
A read is free. A posting to a client's ledger is not — some systems don't even offer reversal. Our agency budget tracks reversibility: reversible work runs autonomously, irreversible work is gated at the exit, always, with a reviewer and a human. You'll move fast and you'll be stopped hard, and both are the job.
03
The state of the code is not the real state.
Migration files are not the database. Mocks are not the API. Green CI has meant nothing, repeatedly. Bugs concentrate exactly at the boundaries where someone trusted the shape of a system instead of going to look. The engineer we want is the one who goes and looks — by reflex, unprompted, before claiming anything at all.
04
The domain has opinions.
Accountants and controllers have been doing this for a long time and are right more often than software assumes. When the system disagrees with an expert, the presumption is that the system is wrong. Engineering that can't hold that posture doesn't survive contact with a client.
The Work
05 — What you'll work on
Representative, not exhaustive.
Agent runtime
Proposer/reviewer loops, confidence policy, tool-calling over enterprise systems, evaluation harnesses that make regressions visible instead of mysterious.
Multi-tenancy done properly
Isolation enforced by the database, not by the discipline of whoever is writing. Entitlements with a single source of truth. This is a commercial and liability boundary, not tech debt.
The write path
The gates, the audit trail, the identity of who acts, the failure semantics. Getting this right is most of the trust.
Boundaries with enterprise systems
ERPs and financial platforms are hostile, badly documented and idiosyncratic. Probe in a real environment before declaring a boundary functional. Fixtures are born from captured real responses, never from imagination.
Joint venture incubation
Being part of the incubation of a joint venture with a multinational group.
Theory
06 — Why theory matters
This is a domain new enough that nobody has a playbook yet.
When you decide how much autonomy to give an agent, where to place the reviewer, what "confidence" means in a number, or why a model hallucinates precisely there and not somewhere else — you won't find the answer on Stack Overflow. You'll have to derive it.
That's why we want someone with a serious theoretical foundation. Not because we like credentials, but for three practical reasons:
Why we ask for it
Telling what's possible from what's hype
Half of what's claimed about agents today is false, and the other half is possible but nobody has built it yet. Knowing where to draw that line — with credibility, not by instinct — saves us quarters.
Knowing what has already been solved
A large share of the problems that look new in agentic finance are versions of old ones: verification, consensus under uncertainty, decision theory with asymmetric costs, distributed systems, control. Someone who knows the literature doesn't badly reinvent what already exists well.
Arguing from first principles
When the system's behaviour is surprising — and it will be — the question is why, not which workaround. We need someone who can reason from the mechanics, not the anecdote.
We're not asking for a PhD. We're asking for someone who reads papers and knows how to critique them, who understands the mathematics underneath what they use, and who can explain to a CFO — without overclaiming and without hiding behind jargon — what these systems can and cannot do.
The Fit
07 — What we're looking for
Four qualities, in order of rarity.
Scepticism, applied to your own work
The rarest quality and the one that counts most. You should feel uncomfortable saying something works before you've watched it work.
Judgment at the boundaries
Knowing which decisions are cheap to reverse and which ones you only get one attempt at — and spending your caution accordingly.
Fluency driving agents
If you're still typing everything by hand, you'll be slow. If you ship whatever comes out of the model, you'll be dangerous.
Honesty under commercial pressure
There will be moments when claiming a capability we haven't built would help close a deal. We don't — not even between ourselves.
Background
08 — You probably already have
What tends to be true of the right person.
- A credible, living theoretical foundation. Solid training in a quantitative discipline — computer science, mathematics, physics, engineering, economics, operations research — or a self-taught path that stands up to the same scrutiny. It matters less where you studied; it matters that you keep reading the state of the art, that you can read a paper with a critical eye rather than a reverent one, and that theory informs what you build instead of sitting on your CV. Published research is welcome, not required.
- Production systems where being wrong had real consequences — payments, fintech, healthcare, infrastructure, trading. Not demos.
- Serious Postgres. Row-level security, not just an ORM.
Seven more
- Cloud fluency. We're on AWS: ECS/Fargate, SQS, Secrets Manager, Bedrock.
- TypeScript and/or Python.
- Claude Code as a daily working instrument — not experimenting, but shipping with it: discovery before implementation, explicit stop gates, one logical unit per PR, diff review before merge.
- Experience with the Claude Agent SDK / API — agent loops, tool use, context management across hops; an agent with write access is an architecture decision, not a feature.
- MCP (Model Context Protocol) — building servers and tools, not just consuming them. Understanding that tool design is product design.
- LLM systems in production — not prompt engineering, not a RAG demo.
- A scar from a non-deterministic system, and you can describe it precisely.
Not Required
09 — What you don't need to have
Three things we don't ask for.
Knowing finance
We'll teach you the parts that matter and shield you from the rest.
A PhD
Not even a Computer Science degree — as long as the foundation is there.
Being a '10x engineer'
A 1x engineer with excellent judgment and a very good model is worth more, and that's what we prefer.
The Process
10 — How this moves forward
Two conversations. No whiteboard.
No whiteboard, no algorithm puzzles, no unpaid weekend project.
In the first, we put a real unsolved problem on the table — not a sanitised version — and we think about it together, out loud. It doesn't matter whether you reach the right answer. It matters how you think when you don't know.
In the second, you take us to the bottom of a system you built, down to the layer where even you aren't certain any more.
If at any point you tell us I don't know, I'd have to go and look — that counts in your favour.
The conversation you'll want to have
You'll want to know what this actually is — compensation, equity, how the day-to-day works, who we are to you and who you'd be to us. We're not going to answer that on a recruitment page. We'll answer it in the first conversation, plainly and without vagueness, because that's how we like to work and because it's the least we owe someone who is doing fine where they are. What we can tell you now: we're not asking you to trade salary for a promise.
Apply.
Tell us about a system you built where being wrong had consequences — and what you'd do differently now.