Principal Founding Engineer, Agent Systems

ABOUT NOUMENAI

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.

This is 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 ROLE

You're a founding engineer, 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.

WHAT THIS DOMAIN DEMANDS

Agentic finance is not a normal software problem. Four things make the difference:

1. The failure mode is being confidently wrong. A model produces a plausible number for anything. 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.
2. 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.
3. 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. The engineer we want goes and looks — by reflex, unprompted, before claiming anything at all.
4. The domain has opinions. Accountants and controllers are right more often than software assumes. When the system disagrees with an expert, the presumption is that the system is wrong.

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
• 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; fixtures are born from captured real responses, never from imagination
• Joint venture incubation with a multinational group

WHAT WE'RE LOOKING FOR

Four qualities, in order of rarity:

• Scepticism, applied to your own work. 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.
• 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.

YOU PROBABLY ALREADY HAVE

• 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. You keep reading the state of the art and can read a paper critically rather than reverently. 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.

YOU DON'T NEED

• Knowing finance. We'll teach you the parts that matter and shield you from the rest.
• A PhD. Not even a CS 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

Two conversations. 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 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.

Compensation, equity and how the day-to-day works: we answer that in the first conversation, plainly and without vagueness. What we can tell you now: we're not asking you to trade salary for a promise.