Why we build teams of agents, not one big one

The obvious way to build an AI for operations is one capable model with access to everything, told to get the job done. It demos well. In production it is hard to trust, because when it goes wrong you can't tell which part of the job went wrong.

So Velocity is built the way a good operations team is: as specialists, each with one job, handing work to each other with the evidence attached.

What a team looks like

Take a supplier invoice stuck in payables. One agent researches — pulling the email thread, the delivery note and the ERP record into one case. Another handles procurement — finding the right item code with the order owner and correcting the order line. Another works with the warehouse to get the receipt posted. A finance agent matches order, receipt and invoice and returns it to the payment run.

Each agent has a narrow brief, a defined set of systems it may touch, and a clear output the next one can check. When something is wrong, it is wrong in one place, with a reason you can read.

Why narrow beats general

• Checkable: every hand-off is a record — what was found, from where, and what was concluded.
• Bounded: an agent that only searches the item master can't post a payment, however it is prompted.
• Parallel: research, stock checks and supplier chasing run at the same time, around the clock.
• Replaceable: a better model for one job improves that job without retesting the rest.

Learning the house rules

Before a team runs anything, it learns how your operation works: past transactions, standard operating procedures, the approval matrix and delegated powers. The way a senior hire does — by reading what the organisation already wrote down, and asking about what it didn't.

Your people keep the judgement and the final say. The agents take the chasing between systems.