The request in the drawer

Almost every .NET software house has a request that never got an answer. A long-standing client asked for something involving blockchain, or an agent that would classify documents inside their ERP, and the answer was no. Not because it was a bad idea: because building that capability is a two-year detour from what the team is already good at.

The reason is more technical than it looks. The API layer of an agent can be written by anyone with real .NET experience: calls, serialisation, an endpoint, a couple of tests. The rest is the part nobody can estimate, and it is the part that decides whether the project reaches production or dies in acceptance testing.

What the estimate misses

Prompt regression, to begin with. Every model version change can shift behaviour on cases that worked fine last month, and you need a suite that notices before the client does.

Then retries. An agent writing to live data cannot repeat an operation without idempotency guarantees: the same invoice approved twice is an accounting incident, not a frontend bug.

Then tool call authorisation, per tenant and per user, because an agent reading a document archive inherits in one move every permission problem the application spent ten years solving.

And finally the decision log, which is where most pilots stop. It is not one more table in the same schema as the application: that table can be rewritten by anyone with database rights, and nobody can prove it wasn't. For high-risk systems the EU AI Act requires automatic event logging. A log the system operator can edit is not proof.

Taken together, those four things are not a feature. They are an operational surface you have to keep staffed over time, and no fixed-price quote covers it.

What the drawer costs

So the request goes in a drawer, and in the short term that is a reasonable call. The problem arrives later: eighteen months on, the client finds a systems integrator who brings the whole package, and the relationship goes with the package. You don't lose a project, you lose an account.

A third option

There is an option between "hire a team" and "say no": take the engineering capacity from outside and keep it inside your own perimeter. In C#, inside the software house's repository, under its brand.

Three areas, and they are the ones I work in: AI agents running in production inside enterprise .NET systems, smart contracts and tokenisation, and the point where the two meet — the agent's decision ledger hashed and anchored on chain, so a third party can verify without having to trust you.

The terms are the only ones that make this workable both ways: standard NDA, day rate, no-poaching clause in both directions. The client stays with the software house. The codebase stays in its repository.

Which request did you say no to that you would have taken, if the capability had been there?