Half the answer is always in another system

Our agent is good at a narrow thing. Around a hundred and twenty tools, roughly a hundred and forty thousand traced runs a month, over a book of close to a million transactions and well past a hundred thousand documents. Create an invoice, categorise a transaction, pull a VAT report, check a tax number.

And it kept hitting the same wall. Almost every genuinely hard bookkeeping question needs something Norman does not hold. The bank line says one number. The reason for that number lives in a payment processor, an inbox, a shared drive, or a system somebody built themselves.

So the agent is an MCP client now. You connect the tools your business already runs, and it reads from them inside the same conversation that files your VAT. It runs in production, labelled Beta, dormant until you connect something.

Here is what that actually buys you.

The rule that shapes everything: read outside, write inside

One design decision drives every use case below, so it is worth stating before the examples.

Sources from our catalogue are read-only. They answer questions. They never change anything, not in Norman and not on their own side. Every write that comes out of the conversation is performed by Norman's own tools, on Norman's own data, with the same validation and the same audit trail as if you had clicked the buttons yourself.

The exception is a server you point us at yourself, because it is yours. There, write tools can be switched on, but only by the company owner, explicitly, and we record who did it.

That is not just a safety position. It is what makes the thing usable at all: you can connect a payment processor without handing an assistant the ability to move money inside it.

Use case 1: the payout that is really forty things

A payment processor pays out once. Your bank shows one credit.

That number is a net: gross sales, minus platform fees, minus refunds, minus a chargeback, plus a payout from the previous period that landed late. As a bookkeeping entry it is close to useless, and reconstructing it by hand is where a lot of people quietly give up and book the whole thing as revenue.

With a processor connected, the question is just "what is in the payout from the 14th". The agent reads the payment, invoice and balance data from the source, comes back with the breakdown, and then uses its own tools to book it: the gross side, the fee side, the refund side, each as its own line against the right transaction.

The reading happens outside. Every entry that lands is written by Norman.

Use case 2: the receipt that exists, just not here

We hold well past a hundred thousand documents, and the ones that matter most are the ones nobody ever uploaded. German bookkeeping runs on documents. A card payment with no Beleg is an open question at the end of the quarter, and that document almost always exists, sitting in a mailbox or a shared drive Norman never had access to.

With a mailbox or a document store connected, "find the invoice for this payment" becomes a search across content you already own. The agent matches on the things that actually identify a document: the amount, a date window around the transaction, the vendor, an invoice number when one is visible.

What comes back is not a file dump. Where a source returns documents, the results arrive in chat as candidates, each one a card with an import action. You pick the right one, Norman fetches the bytes itself, and the document lands attached to the transaction, categorised, sitting where you need it at the end of the quarter.

The agent never downloads a file on its own initiative. It finds candidates. A human picks.

Use case 3: the debit nobody can explain

A chargeback shows up as money leaving the account. So does a refund, a fee correction, a partial reversal. In a bank feed they look identical, and the correct booking is different for each.

Connect the processor and the agent can read the dispute record, the refund and the original order behind that debit, then book the transaction as the thing it actually is. Refunds are their own small nightmare, because a refund is not a negative sale, it is a reversal that has to land on the side of the books it reverses. Having the source of truth one question away instead of one CSV export away changes how often that gets done correctly.

Use case 4: the server you wrote yourself

This is the one I would build against if I were an engineer running a small company.

Any public HTTPS MCP server can be added as a custom source: your project system, your internal admin, your own database behind a thin server, some scheduling tool your industry uses that nobody else has heard of. Those tools show up next to the bookkeeping ones, in the same conversation:

# what the model sees in one conversation
create_invoice                (Norman)
categorize_transaction        (Norman)
list_tax_reports              (Norman)
studio__list_projects         (your server, namespaced)
studio__get_project_hours     (your server, namespaced)

The prefix is not decoration. Your tools can never be confused with ours, and ours are never exposed to your server.

Which means the questions stop sounding like accounting and start sounding like the business:

• "Which open invoices belong to projects that already shipped?"
• "Match this month's expenses to the client they were incurred for, and tell me which ones I never rebilled."
• "This supplier invoice, does the delivery it refers to exist in our system?"

And because the server is yours, its write tools can be switched on too. After confirming an invoice was paid, the agent can push the status back to where your team will see it. That takes a deliberate decision by the company owner rather than a default, which is about the right amount of friction for something that changes state in a system we do not run.

Use case 5: nothing external at all

Worth saying, because it is still the majority case. "What is missing before the quarterly filing" needs no connected source whatsoever. That is Norman's own tools over Norman's own data, and it is where the agent spends most of its time.

Sources are not a separate product bolted on the side. They are the missing context for work the agent already does. And a source having a bad morning gets marked unavailable and dropped from the run, so you get a working assistant that cannot see that one source, plus a card saying exactly that, instead of an error where an answer should be.

What we deliberately did not build

Briefly, because it shapes what you can expect from it.

Catalogue sources cannot write, at all. Remote tools are shown to the model under a namespaced name, so nothing can impersonate one of ours. Approvals are pinned to the tool list we inspected when you connected, so a server cannot quietly redefine an approved tool afterwards. And whatever comes back from a source is data, never an instruction: an email politely asking the assistant to send money somewhere is text, and text has no authority here.

That is the short version. The long version is a different post.

The ceiling was never intelligence

The thing I keep coming back to: for an agent doing real operational work, the binding constraint is almost never how smart the model is. It is what the model can see.

Ours could always categorise a transaction. It could not tell you why a payout came in a few hundred euros under the sales it covered, because that answer lived in a system it had no eyes on. Nothing about the model changed. The access did.

When this works properly, you will not notice it working. You will ask where a receipt is, and it will be there.