Approach
How an engagement actually runs.
We are new as a company, so we will not ask you to trust a history. What we can do is state exactly how we work before you commit to anything, and then be held to it.
The shape of a first engagement
Five stages. The first two produce a document, the third produces working software, and the last two are what most suppliers leave out. Each stage says what we need from you, so the cost of working with us is visible before it is incurred.
- 01
Read the operation
We spend time with the work as it is: the spreadsheet with the manual column, the phone call that unblocks everything, the exception everyone knows about and nobody wrote down. This is done with the people doing the job, not only with the people who commissioned the project.
What this costs you
A few hours with the people who do the work, and permission to look at real cases rather than a sample.
- 02
Agree what done means
Acceptance criteria in writing before anything is built: what the system must handle, at what accuracy, on which cases, and what it must refuse to do. If we cannot write them, the scope is not ready and building would be guessing.
What this costs you
One person with the authority to approve the criteria, and one pass of comments on our draft.
- 03
Build the first slice
One narrow capability, running in your environment, at a fixed scope and a fixed price with a date. Narrow enough to finish, real enough to use. We would rather one team depends on it than five teams have seen it.
What this costs you
Access to a test environment, and somebody we can ask when a field turns out to mean two things.
- 04
Measure before you trust it
We run the system against a set built from your own historical cases and show you where it fails, not only where it succeeds. Then you decide what to widen.
What this costs you
Historical cases we can build the test set from, and an hour to read the results with us.
- 05
Hand over the keys
Code, infrastructure, documentation and training. The test is simple: your team makes a change without us in the room. Until that has happened, the engagement is not finished.
What this costs you
Two people from your side in the training, and one change they make while we are not there.
The bounds we put on a system
Four questions get asked in every procurement conversation about agents. We answer them before they are asked, and the answers are mechanisms rather than reassurance.
What is it allowed to do?
A written, enumerated list of permitted actions, agreed with you. Anything outside the list stops and asks. The boundary lives in configuration, not in a prompt that might drift.
What did it do?
Every case carries its input, its decision, its sources, its output and its approver. Readable months later by someone who was not there, and exportable.
Who approves the irreversible?
Money moving, a contract issued, a record deleted, a customer told something final. Those pass through a person by design, with the draft prepared so the approval takes seconds.
How do we stop it?
One switch per capability, reachable by someone who is not an engineer, effective without a deployment. If a system cannot be stopped quickly it should not be started.
Measurement is a deliverable
Before an agent handles a case type, we build an evaluation set from your own historical cases and we publish the results — including the failures. An accuracy claim without a test set behind it is a sentence, not a fact. The set stays with you and it is what you re-run when a model provider changes something underneath you.
Ownership and exit
The strongest thing a new supplier can offer is that leaving is easy.
Yours from the first commit
Code, prompts, evaluation sets, infrastructure definitions and documentation. In your repository and your accounts, not ours.
No credential held only by us
Every account, key and environment is owned by you and shared with us, never the other way round.
An exit written at the start
What handover includes, how long it takes, and what it costs — agreed in the first contract rather than negotiated when the relationship is already strained.
Data and where it runs
Deployment is a decision with consequences, so we write down what changes in each case rather than defaulting to whatever is easiest for us.
Your environment, our managed environment, or your own hardware
Three options with three different data-flow diagrams. You choose, and the diagram for your choice goes in the architecture document.
Model access is stated, not assumed
Which provider handles which step, what leaves your perimeter at that step, and what the alternative is if it must not. Where the answer is that nothing may leave, we design for that from the start.
Your data is not training data
We do not train on your content and we contract on that. Retention periods are set by you and enforced by the system, not by a policy document.
What we do not claim
We hold no certifications and we will not imply otherwise. We have no client list to show you and we will not invent one. What we have is finished software you can open right now, a method written down in enough detail to be argued with, and terms that make leaving us cheap. If a supplier with a longer history is the safer choice for your case, that is a reasonable decision and we will say so.
Ask us a hard question about this page.
The parts of this method that matter are the ones you can test. Push on one.
Our WhatsApp line is being connected. Email reaches us today.