Two fears sit behind every question about ongoing support: that the vendor disappears the day after handover, or that you can never get away from them. This page is how we've structured things so neither happens.
Almost nothing we do after launch is bug fixing. Three things move underneath a working agent, and none of them are defects in the code.
Your CRM ships a new version. A field is renamed. An API deprecates an endpoint with ninety days notice that nobody forwarded. This is the most common cause of an agent quietly doing the wrong thing.
Policies get updated, products change, a pricing rule from last year no longer applies. The agent keeps citing the clause it was given — accurately, and wrongly.
A new customer segment arrives with a ticket type nobody anticipated. Volume moves between categories. The agent handles what it was tuned for, and the shape of the queue has moved.
This is why we're sceptical of "set and forget" claims in this category. An agent connected to five living systems inside a changing business is not a finished artefact. It behaves like production infrastructure — mostly quiet, occasionally needing attention, and worse the longer that attention is deferred.
Not a dashboard someone might check. A mechanism that acts without waiting for a human to notice.
Listed first, deliberately. If your platform team wants to own this, that's a legitimate outcome and we build for it.
Swipe →
Your engineers take the system at handover and run it. We stay reachable for questions for ninety days at no charge, then you're independent.
Monitoring, upstream API changes handled, incident response, accuracy reporting. No new features — this tier keeps what exists working.
Everything in Tier 1, plus a monthly working session where we review accuracy by category, agree what to tune, and ship it. A steady trickle of improvement rather than a project.
A named automation engineer in your standups and your tools, working your backlog. Support becomes a side effect of them being there rather than a separate contract.
Tiers move in both directions and there's no minimum term on any of them. Several clients sit at Tier 3 during an expansion phase and drop to Tier 1 once things settle. That's the system working, not churn.
The same agenda every month, so it doesn't degenerate into a status call.
Numbers first, before anyone's impressions. Anything that moved more than a few points gets explained before we discuss anything else.
The edits your team made are the highest-value signal in the whole system. Recurring corrections become the tuning list, in order of frequency.
Which have earned less review, which need more. We recommend; you decide. Nothing changes autonomy level without you saying so in this meeting.
Vendor deprecations, your own planned system changes, a migration someone mentioned in passing. Far cheaper to handle before it lands than after.
Ten minutes at the end. Often nothing — and a month where the answer is "nothing yet" is a perfectly good month.
Published, because a vendor unwilling to write this down is telling you something.
No minimum term, no exit fee, no clawback of anything already delivered. An email is sufficient.
The source is already in your repository and it's already deployed on your infrastructure. There is no migration, because there was never anything on our side to migrate from.
Credentials revoked by you, confirmed by us in writing. The full audit trail stays in your systems, where it always was.
Two hours with your engineers or your incoming vendor, walking the runbook and answering whatever they ask. Included, not chargeable.
Clients have left, run things themselves for a year, and come back for the next agent. That's a good outcome. A client who stays because leaving is painful is not a reference.
Inference is billed to your own provider account, so pricing changes reach you directly rather than through our margin — you can see exactly what the system costs to run. Migrating to a replacement when a model is deprecated is covered under Tier 1 and above, because the reasoning layer is deliberately model-agnostic and swapping is configuration rather than a rebuild.
No. It's your code and we'd rather you were capable of changing it. Practically: work on a branch, keep the contract tests green, and mention it at the monthly session so we don't spend an afternoon debugging something you changed on purpose. Several clients have taken over incrementally this way, which we consider a success rather than a loss.
An incident is the agent acting wrongly or not acting at all — not a draft someone disagreed with. The first response is almost always the same: reduce autonomy on the affected categories so humans are back in the loop, then diagnose. Restoring correctness comes before restoring automation, every time.
Your configuration, your rules, your data and anything specific to your business stay yours and go nowhere. Generic engineering improvements to shared components — a better retry strategy, a fix inside a connector — do flow back into the registry, which is also why your build started at roughly seventy per cent reuse. If you'd rather that didn't happen, say so at contracting and we'll fork the components for you instead.
More common than any technical failure, and the most likely way a working system quietly decays. Tell us and we'll run an onboarding session for their replacement covering what the agent does, what it deliberately doesn't, and which decisions were made on purpose. Included in every tier — an unowned agent is a liability for both of us.
Five days, no cost. We map one workflow and tell you honestly whether an agent belongs in it. Support tiers are a conversation for much later.