How we decide.

Why

It is easy to fall in love with a tool and start looking for problems it can solve. That is backwards. Nobody hiring an agent cares which model is behind it or where it runs. They care whether the stranger who asked a question at eleven at night got a right answer.

In practice

• A role is described by what it answers, not by what it is built on.
• The two weeks are judged on drafts you would have sent, not on a score we report.
• If an agent is not the right answer, we say so before you pay for one.

What this costs

We will sometimes talk somebody out of buying.

Why

Offering something the product cannot do is worse than not offering it, because the client finds out after they have committed. This is not a hypothetical: a channel sat in the picker for months with no adapter behind it, accepted by the database and throwing on every message. It was removed rather than left broken, and came back when it existed.

In practice

• A channel is listed when its adapter is written, and not before.
• A role reaches the price list after it has answered real messages.
• When a claim on this site turns out to be false, the claim goes, not the evidence.

What this costs

The catalogue is short and fills slowly. That is the shape of the rule, not a stage we are passing through.

Why

Most technology projects fail not because the code is bad but because the structure is wrong, and a bad foundation cannot be fixed with good implementation. Rethinking it afterwards costs more than thinking first. We have never measured how much more and will not put a multiplier on it.

In practice

• The decision is written down where the code is, so the next person inherits the reasoning and not just the result.
• "What breaks when this assumption changes?" is a standard question.
• A guess that cannot be checked does not ship as a fact.

What this costs

We are sometimes slower to start.

Why

Complexity feels productive and is usually debt. Every layer adds a surface that can fail. The right amount is the minimum that solves the actual problem, not the problem you imagine might arrive later.

In practice

• The first version of anything should be embarrassingly simple.
• "Do we actually need this?" is always a valid question.
• If a spreadsheet solves the problem, we use a spreadsheet.

What this costs

What we build looks less impressive in a demo. It lasts longer in production.

Why

Everyone says they value honesty and almost nobody builds systems that make dishonesty structurally difficult. Culture drifts and processes persist. The two weeks are this principle as a product: the send path is closed rather than discouraged, so the agent staying quiet does not depend on the agent agreeing to.

In practice

• Every reply is kept against the version of your knowledge that produced it, so a wrong answer has a cause you can find.
• A question the agent could not answer is recorded as a gap, not covered with a guess.
• The gate that holds a reply is a closed path, not an instruction the agent could misread.

What this costs

We cannot present a tidy version of a messy reality, on this site or in your queue.

Why

This is a managed service. The agent runs on our infrastructure rather than yours, and pretending otherwise would be the lie this page exists to prevent. What that cannot be allowed to mean is that leaving is hard. Clients should pay us because it is easier and better, and the moment somebody stays because switching hurts, we have failed a different way.

In practice

• Knowledge, conversations and sent replies export in formats you can read without us.
• Stopping an agent is one click, with no ticket and no notice period.
• A cap you set is a cap we honour, so the bill cannot outrun the decision.

What this costs

Clients can leave the day they decide to. That means we have to keep being worth staying for.

Why

The other principles could justify never shipping. "Not architecturally perfect." "Could be simpler." That is a trap, and the only way to know whether something works is to let reality have it. But shipping and selling are different acts, and collapsing them is how a demo becomes a promise. Fast is for the build. Slow is for the claim.

In practice

• "What is the smallest version we can ship this week?"
• A feature that works and a feature that is advertised are two separate decisions.
• Every failure is a data point, and it is written down where the next person will find it.

What this costs

We ship things nobody is told about yet. Being quiet about something new is fine. Being wrong about it, as this site was about ten channels in August 2026, is not.