imfund: two people and an entire company of AI agents

Alongside my consulting work through BBIMP, I'm helping build imfund together with Mauricio Garcia, who runs the company. imfund is a platform for fund and asset managers covering portfolio management, risk, compliance and fund operations, with AI agents built into the product – always under human control.

What makes imfund unusual isn't just the product, but how it's built. There are two of us. The rest of the organisation is AI agents.

See the full org chart, the house rules and every job description →

An org chart, not a prompt

Most "AI agent" setups are, in practice, a single assistant with a long prompt. imfund is organised like a company instead. The agents run in Paperclip, an open-source framework for directing and coordinating AI agents – a so-called meta harness. Paperclip works as the office: org chart, tickets, scheduled wake-ups, budgets, approvals and a log that can't be altered after the fact.

Every agent gets what a new hire would get:

• A manager. The Engine developer reports to the Architect, who reports to the Chief of Staff, who in turn reports to the board – Mauricio and me.
• A job description. A mission, responsibilities, what the agent has access to, what "done" means – and a list of things it must never do.
• A schedule (heartbeat). When the agent wakes up: when it's assigned a ticket, every morning at 07:00 or, for the reliability agent, every fifteen minutes while the US market is open.
• A budget. A monthly spending cap, so an agent stuck in a loop can never cost more than a known amount.

Today 16 agents are running across five departments: Engineering, Security & ISMS, Product & domain, Clients & growth, and Finance & operations. They include an Architect, backend and console developers, a QA engineer, an independent code reviewer, a product manager, a risk quant, a compliance analyst and a market researcher.

Hiring in phases – like any other company

The organisation grows in three phases, as the need arises, just like a company with employees:

1. Phase A – now. The core: Chief of Staff, Architect, developers, QA, code review, security and product management.
2. Phase B – the first clients. Operations, integrations, documentation, fund operations, risk and compliance – followed by onboarding and pre-sales once the first client is on board.
3. Phase C – the full product. Trading systems, data engineering, evaluation of AI models, data protection, support and content.

The rule is simple: an agent is hired only when a queue of tickets is waiting for it. An agent with nothing to do still costs money every time it wakes up.

What only humans decide

This is the part I think matters most. The agents do the work – but every decision that carries accountability stays with us humans.

• I hire agents, set their budgets and hand out credentials.
• Mauricio owns client contact, sets prices and dates, and approves anything a client will read.
• Together we choose which cards the agents may start on, accept finished work and merge the code into master – which is the moment it goes to production. We also set the company's goals and decide on anything regulated. Legal, tax and accounting questions also always go to a qualified outside professional.

No agent can create another agent, push code straight to production, email a client or give a final answer on a regulated question. All of that stays a draft until a human has reviewed it.

From Triage to Done – with a human in the loop

In practice, the collaboration is most visible on the project board in Jira. Every card moves through the same five columns, with a clear split of who may move it on:

1. Triage. New ideas, bugs and requests land here. The agents help write the cards – with acceptance criteria, open questions and dependencies – so they're clear enough to build.
2. To Do. Mauricio or I move a card here when we judge that the agents can start on the feature. No work begins before that.
3. In Progress. An agent picks up a card from To Do and moves it here when it starts working. The work happens on its own branch, never directly on master.
4. In Review. When the agent is done – with tests, verification and a comment on what it did – it moves the card here and opens a pull request. The code is first reviewed by an agent from the other model family.
5. Done. Only a human can move a card here. Mauricio or I check the result, approve it and merge the agent's branch into master.

So the agents do most of the work, but the two most important decisions – what gets built and when something is finished – are always made by a human.

The house rules

Every agent's instructions open with the same ten house rules, ahead of the job description itself. A few of them:

• Work only from tickets. No work starts on a card that hasn't been prioritised.
• Never push straight to master. Open a pull request and let a human approve it.
• Whoever writes the code never reviews it. Code from one model family is reviewed by the other.
• No client data by default. Only when a human has opened a support grant – and only for that ticket.
• Stay within budget. Stuck twice on the same step? Stop and escalate instead of trying again and again.
• Leave evidence. Every run ends with a comment: what changed, what was verified, what wasn't, and what the next step is.

Two model families – on purpose

The agents run in two different environments: Claude Code for architecture, backend, security, product, design, operations and risk, and OpenAI's Codex for the console, integrations, QA, code review and several analyst roles. The split is deliberate. When the author and the reviewer come from different model families, they don't share the same blind spots – for the same reason a developer shouldn't approve their own change.

It's also important to separate two kinds of AI here. The trading desk and the portfolio manager agent inside imfund are product features. They're governed by the client's mandate and a policy engine, not by the org chart. The company's agents build and test them, but never act in their place.

Hermes Agent – the portfolio manager

The portfolio manager inside the product runs on Hermes Agent, an open-source AI agent from Nous Research, released under the MIT licence. Unlike coding tools such as Claude Code and Codex, Hermes is a general-purpose agent built to work over long periods and learn as it goes. It has persistent memory, turns experience into reusable skills that it refines over time, and can search its own earlier conversations. It also handles scheduled tasks, MCP tools, several execution environments and isolated profiles, where each profile has its own memory, skills and settings.

Those isolated profiles are exactly what make Hermes right for imfund. The fund's portfolio manager has its own profile, bound to the client's mandate, and a policy engine checks every decision before anything is executed. None of the company's agents may touch that profile. Hermes is also set to run several upcoming roles – onboarding, pre-sales, support, content and finance – each with its own imfund-* profile via OpenRouter. That way, the model behind each role can be chosen for its task and its cost.

The stack

imfund deliberately relies on a small number of managed cloud services, so that two people – and their agents – can run the platform without an operations team of their own.

The backend consists of two Python services on Railway: the Engine, which holds the API, the policy engines and the trading desk, and the Worker, which runs background jobs and scheduled tasks. Both use PostgreSQL on Neon. Events are only ever appended – nothing is updated or deleted – which gives full traceability from the start. Thanks to Neon's database branching, every new feature can get its own copy of the database for development and testing, and no agent ever touches the production database. Client-specific information lives in a separate database of its own, kept apart from the shared platform data. The frontend – the console that clients and admins actually see and work in – is built in Next.js and hosted on Vercel, which serves it quickly worldwide and deploys each approved change automatically.

On top of that sits the agent layer. Paperclip writes no code itself; it organises the agents that do: who reports to whom, which ticket they're on, when they wake up and how much they may spend. The company's agents run in Claude Code and Codex, while Hermes Agent runs the agent inside the product. Every company agent starts with a locked-down configuration – no access to production environments, cloud tokens or paid API keys.

At heart, a governance question – which is why it feels familiar

What strikes me after some time working this way is how little of it is really about the models themselves. Almost all of it is about governance: clear ownership, defined roles, rules for who may change what, traceability and segregation of duties.

That's exactly what I've worked with for more than ten years in master data management and data migration. A golden record needs an owner and rules for approval – and so does a pull request written by an agent. A migration needs reconciliation to prove it was correct – and an agent needs to leave evidence of what it has verified. imfund is also working towards ISO 27001, and every agent is treated as an identity with access: it's included in the monthly access review, has its own keys and is listed on the supplier register.

My conclusion: good AI engineering is mostly good data governance. The organisations that already have ownership, rules and traceability for their data are the ones best placed to put AI agents to work safely.

Thinking about using AI agents in your own business – on top of data from ERP, MDM or a migration? Get in touch.