Diligence that travels

You win the deal in six weeks. Then the review starts, and that takes another twelve. Security sends a questionnaire. Legal wants to know what the agent is allowed to do. Risk wants to know what happens when it gets something wrong. Your team answers from memory and pastes screenshots into a document nobody will open again.

Three months later you sign. Then the next customer arrives, asks the same questions, and you start from nothing.

What the review is actually asking #

Strip the formatting and an enterprise review asks three questions.

• What is this thing allowed to do? Where does it stop and ask a person?
• What has it actually done? Not in a demo, but in production, for customers who are not us.
• What happens when it gets something wrong? Who is on the hook, and what does our side receive?

Everything else on the form is a proxy for those three. The buyer is not auditing your company. They are working out whether they can put your agent somewhere it can do damage.

Why it starts from zero every time #

You can answer all three. The problem is the form the answers arrive in: prose in a document, a screenshot of a dashboard, and a call with the one engineer who remembers what happened in March. None of it can be checked by the person reading it. They have to take your word for it, which is what a review is supposed to avoid.

So every buyer rebuilds the answer from scratch. The work you did for the last customer does not carry over, because it was assembled for that customer rather than produced as the system ran.

The cost lands on the pipeline, not the security budget #

A quarter per enterprise deal is the obvious cost. The less obvious one: the same three people answer every questionnaire, so you can only run a few reviews at a time. Your enterprise pipeline is capped by one person’s calendar.

A slower cost sits underneath. A track record that lives in screenshots and one person’s memory does not survive that person leaving. Every year, some of what you have already proven quietly stops being provable.

What travels and what does not #

Some things already travel between buyers, and most say little about your agent. A customer reference travels, but it is an opinion, and the buyer discounts it because you chose who to put on the call. A certification says something real about how your company is run. Neither says much about what your agent did last Tuesday on a task like the one your buyer has in mind.

What would travel is a record of what the agent was allowed to do and what it did, produced while it ran rather than written up afterwards, in a form someone who was not there can verify.

A record that travels #

That record is something you can hand over. It is not a certificate or a score. It is a history, and a useful one carries five things.

• The mandate. What each run was allowed to do, set before the run rather than described afterwards.
• The behaviour. What the agent actually did inside that mandate.
• The stops. Where it reached the edge of what it was allowed to do and handed the decision to a person.
• The failures. The runs that went wrong, what was owed, and who settled it.
• The names. Who accepted each mandate before the agent ran.

The fourth matters most. A record with no failures is a brochure. Anyone who has operated real systems knows that something which has never failed has probably not been exercised enough. A spotless record earns less trust, not more.

Why the record is yours, not the customer’s #

This is what makes it a commercial asset rather than a compliance chore. Each customer sees only its own deployment, a slice that is small and recent. You are the only party present across every run and every customer, back to the first one. The full record accumulates in exactly one place, and that place is the vendor.

So it compounds. The second enterprise deal is easier than the first, not because you got better at filling in forms, but because you arrive with eighteen months of history the buyer can inspect instead of interviewing you.

It is also hard to copy. A competitor with a better demo starts where you started, with nothing behind it. Demos are cheap. Two years of behaviour under stated terms is not.

It changes the meeting too. Today you ask a buyer to believe a description of your agent. With a record in front of them, they can check a fact instead of judging your credibility. Only one of those should take a quarter.

Where Tidestone sits #

Tidestone is an accountability layer for financial agents. It sits at the point where a task is defined and funded. You set the mandate, controls, and success conditions before each run, and you define the failure terms and payout path.

The record of all that is raw material for the history. It emerges as a by-product of running the work properly, which is the only practical way this history gets built. Nobody sits down and writes a track record on purpose.

Tidestone is software. It does not provide or arrange insurance, recommend capital, custody funds, or act as counterparty to an operator’s clients. A remedy is the operator’s own promise to its client, funded by the operator or a funding provider under separate terms.

Tidestone is in preview and runs in a sandbox. What is described here is what the record is designed to support, not something you can hand a buyer this quarter.

The short version #

Every enterprise buyer asks the same three questions, and every vendor answers from scratch because the answers exist only as prose and screenshots. They could instead exist as a record: what the agent was allowed to do, what it did, where it stopped, what happened when it failed, and who accepted each mandate.

That record belongs to you. Each customer sees one slice. You see all of them.

The first review may still cost you a quarter. The tenth should cost an afternoon, and the difference is an asset, not just a saving.