Why our engineers sit with customers, and what they are not there to do

Every platform company eventually offers some version of this. An engineer works with a customer for a period, and something gets built faster than it otherwise would.

The question is what state the customer is in when that engineer leaves, and it depends entirely on what the engineer was optimising for.

The failure mode

The engineer builds the thing. It works, the customer is pleased, and the knowledge of how it works leaves with the engineer.

Six months later the agent needs changing, nobody internally understands the evaluation criteria, and the customer opens a support ticket to modify their own system. That is dependency, and it can be dressed up as a successful engagement for quite a long time.

It is also commercially tempting in the short term, which is why it happens so often without anyone deciding it should.

What we are actually there to do

Teach the four things that make agent operations work, by doing them together rather than for them.

How to decide what to automate first, which is usually a narrower choice than the customer's instinct.

How to write evaluation criteria for their own work, which is the skill that transfers furthest and the one nobody arrives with.

How to instrument cost and ownership so that the second agent does not repeat the first agent's mistakes.

How to set a boundary and enforce it at the point of action rather than describing it in a prompt.

If we do those four well, the first agent is slower to ship and the fifth is entirely theirs.

The measure we use

Not agents delivered. Whether the customer built the next one without us.

That is a deliberately awkward measure, because it makes a successful engagement one that ends. We think it is the right one, and it is the test we would apply to a vendor working with us.

What the engineers learn

This runs both ways and it is not a courtesy. Almost everything we have changed in the platform came from watching a team hit something we had not anticipated.

Per-agent attribution being used as an inventory tool rather than a cost tool. Budgets set tight and used as a signal. Evaluation criteria written backwards from a failure rather than designed in advance. None of those came from a roadmap. They came from sitting next to someone.

What we will say no to

Building something we think should not be built. An agent placed in a decision path where being wrong is expensive and there is no review step is not a scope question, it is a design objection, and we would rather raise it than deliver it.

We also decline to be the ongoing owner of a customer's agents. An agent needs a named owner inside the organisation that depends on it.

How to work with us

The engagement is bounded and the goal is stated at the start: your team runs this without us. If you want to talk about a specific programme rather than a general offering, book a demo and bring the constraints.

Next

The Agent Orchestration System pages cover the layers this work is built around. Careers covers what these roles look like from the inside.