Principal Founding Engineer Job Bristol area,England UK,Software Development

Agentic Finance
· UK, Luxembourg, Portugal, Spain, Remote-EU
· Reporting to Founder

Principal Founding Engineer, Agent Systems

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.

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.

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.

Agentic finance is not a normal software problem.

Most excellent engineers aren't automatically good r things make the difference.

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.

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.

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.

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.

Representative, not exhaustive.

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 gates, the audit trail, the identity of who acts, the failure semantics. Getting this right is most of the trust.

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.

Being part of the incubation of a joint venture with a multinational group.

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…