The “Can you check this order?” tax

At 9:02 the message reads: "Can you check order #4821? Customer says it never arrived." The developer answers in ninety seconds. Getting back to what they were doing takes rather longer.

By 11:30 there have been four more. Sales wants to know what Acme ordered last month. Ops needs to know whether #4790 is paid, because the courier is waiting. Support is back, apologetic, with one more order. The owner would like this week's refund count. Five questions, each reasonable, none of them hard.

The cost is not the lookup

Every one of those answers sits in a table the developer could query half asleep. That is exactly why they get asked. The person asking has no way in, and the developer is the shortest route to the data.

The lookup is cheap. The switch is not. Someone in the middle of a migration or a stubborn bug is holding a lot of state in their head, and a "quick one" in a chat window drops most of it. Five of those before lunch and the morning has been spent being a query interface.

Nobody records this. It does not show up in a sprint, a ticket queue or a budget line. It is a tax paid in attention, and it falls on the person whose attention is hardest to replace.

Why it keeps happening

It is tempting to treat it as a discipline problem: batch the questions, write a wiki page, build one more report. None of that changes the shape of it. The questions are ad hoc, the answers live in a database, and the only people who can ask the database are the ones who know its schema.

Handing support a SQL client is not the answer either. A login with read access to production is a liability long before it is useful, and nobody asking "is this order paid?" should need to know what a join is.

Let them ask the system

Caterfli connects to the database, API or MCP server you already run, reads what it can do, and turns each capability into a tool — list_orders, count_refunds and so on — with a risk level attached. An agent built from those tools sits in web chat, Slack, WhatsApp or Telegram. Support types the question the way they would have typed it to the developer, and the agent answers from your own data.

Three things make that safe enough to hand to a whole team:

• Every call is checked. In web chat the agent acts on behalf of the person signed in. Reading needs chat.use, which a member holds; changing anything needs tool.execute, which starts at manager. An agent cannot lend someone a power their role does not include.
• Reads flow, deletes wait. A lookup runs without ceremony. A destructive call stops until a person approves that specific call.
• Every run is traced. Each proposed call, each check and each result is written down, so "who looked at that order?" has an answer.

How far the agent reaches is decided by the tools you give it. A support agent with only order and shipment tools cannot wander into payroll, however the question is phrased.

What the developer gets back

Not a new system to look after. Nothing is migrated and no admin screens are rebuilt; the database carries on doing what it did. What changes is who has to be interrupted for an answer.

The questions do not stop. They just stop arriving in one person's inbox. If support's are the loudest in your week, here is what an order lookup looks like from their side.