Skip to content

How we work

Four steps, in this order, every time.

The order is the method. Nothing is built before it is defined, nothing ships before it is measured, and nothing is handed over without the people who can keep it running.

  1. 01

    Define

    Name the task, the owner and the measure of success before any model is chosen.

  2. 02

    Instrument

    Build the evaluation harness first, so improvement can be told from luck.

  3. 03

    Integrate

    Ship into the existing workflow, with fallbacks, logging and access control.

  4. 04

    Hand over

    Leave the runbook, the tests and the team that can operate it without us.

How we work

  1. 01. Define

    Name the task, the owner and the measure of success before any model is chosen. We sit with the people who run the process, map where it breaks, decide which data the system may see and write down what a good result looks like. If an agent does not belong there, this is where we say so.

    Deliverables

    • The task definition
    • the named owner
    • the measure of success and its target
    • the data access scope
    • a go or no-go on building

  2. 02. Instrument

    Build the evaluation harness first, so improvement can be told from luck. Real cases become a test set, the metrics match the task, baselines are recorded and every change from now on is scored the same way.

    Deliverables

    • The evaluation set from real cases
    • the metrics and baselines
    • the scoring code
    • the first report
    • the sample size needed to tell a difference

  3. 03. Integrate

    Ship into the existing workflow, with fallbacks, logging and access control. The system goes where the work already happens, in the ERP, the CRM, the ticketing tool or the document store, with a path for the cases it must not handle alone and a log of everything it does.

    Deliverables

    • The system in production inside the existing tools
    • access control and permissions
    • logging and monitoring
    • fallbacks and escalation paths
    • the audit trail

  4. 04. Hand over

    Leave the runbook, the tests and the team that can operate it without us. We train the people who will own the system and document how to run it and how to change it.

    Deliverables

    • The runbook
    • the test suite and the evaluation history
    • training for the operating team
    • the documentation

Sample engagement

What six weeks can look like.

Illustrative timeline. Real engagements are sized at the definition step and vary with the process, the data and the team.

  1. Week 1

    Define: workshop with the process owners, data access scoped, measure of success agreed.

  2. Week 2

    Instrument: evaluation set built from real cases, baselines recorded, first report.

  3. Week 3

    Integrate: first version in a staging environment, wired to the systems of record.

  4. Week 4

    Integrate: evaluation gates each change, fallbacks and logging exercised, access control reviewed.

  5. Week 5

    Integrate: production rollout with a limited scope, measured daily.

  6. Week 6

    Hand over: runbook, tests and training delivered; the team operates the system.

Evaluation gates every change.

No prompt, model or code change reaches production without a run of the harness against the baseline. A change that does not beat the baseline by more than chance, at the agreed sample size, does not ship. The same rule applies after hand over, and the runbook says how to run it.

How hand over works.

Hand over is the last step, and it is planned from the first. The operating team is trained on the running system, the runbook covers the routine and the failures, and the tests, the evaluation history and the documentation live in your repository. The system runs without us.