Support & Maintenance

AI systems do not fail the way ordinary software does. They keep running while the answers quietly get worse, because the data changed, a provider updated a model, or a small prompt edit had a side effect. Costs creep up with usage. Without someone watching, you hear about it from a customer. Support and maintenance gives the system an owner who checks it every day and fixes it before anyone outside notices.

Quality is watched, not assumed

We run your test set on a schedule and sample live answers, so a drop in quality shows up as an alert.

Costs stay inside a budget

Usage and spend are tracked per feature, with alerts well before a limit is reached.

Changes are tested first

Updates to models, prompts, and dependencies are checked against your test set before they reach users.

Monitoring and alerting

Dashboards and alerts for availability, speed, errors, and usage, routed to the people who can act.

Quality and drift checks

Scheduled evaluations against your own cases, plus review of a sample of live answers each week.

Cost and usage control

Spend broken down by feature and model, with budgets, alerts, and suggestions for bringing it down.

Incident response

A written process, named contacts, and response times agreed by severity, with a short write-up after every incident.

Model and dependency updates

Provider changes, library patches, and security fixes applied through a tested release, with a way back.

Continuous improvement

A monthly review of what users struggled with, turned into a short list of fixes ranked by value.

• Answers start to get worse

  What we do

  We compare current results with the baseline, find the cause in the data, prompt, or model, and fix it or roll back.

  What you see

  Quality back above the agreed threshold, with a note on what changed.

• The monthly bill jumps

  What we do

  We trace the increase to a feature, a user group, or a prompt, and put limits or a cheaper model in place.

  What you see

  The cause explained, spend back in range, and a new alert so it cannot repeat unnoticed.

• A provider retires or changes a model

  What we do

  We test the replacement on your cases before the deadline and plan the switch with you.

  What you see

  A scheduled change with scores, not an emergency.

• A user reports a wrong or harmful answer

  What we do

  We reproduce it, check the sources, decide whether it is a one-off or a pattern, and add it to the test set.

  What you see

  A reply to the user, a fix, and a test that guards against a repeat.

• A connected system changes

  What we do

  We watch for failing integrations, update the connection, and rerun the tests that depend on it.

  What you see

  The integration repaired, usually before your users notice.

1. Phase 1

   2 weeks

   Take over

   • Review the architecture, access, runbooks, and past incidents
   • Record baselines for quality, speed, and cost
   • Agree severity levels, contacts, and what needs your approval

   You receive

   Service plan, baselines, and gaps in the runbooks closed.

2. Phase 2

   2 to 3 weeks

   Set up watching

   • Add monitoring, dashboards, and alert rules
   • Schedule the evaluation runs
   • Rehearse an incident with your team

   You receive

   Live dashboards, alert rules, and a tested incident process.

3. Phase 3

   Ongoing

   Run

   • Watch the dashboards and respond to alerts
   • Apply updates and fixes through a tested release
   • Keep a log of every incident and change

   You receive

   A monthly service report and an incident log.

4. Phase 4

   Quarterly

   Improve

   • Review quality, cost, and user feedback with your leadership
   • Tune prompts, models, and retrieval where there is a clear gain
   • Retire what is unused and plan what comes next

   You receive

   Quarterly review and an updated improvement backlog.

How we protect your systems

Least-privilege access

We get the access the job needs, through named accounts, and every session is logged.

Change control

Changes are tested, recorded, and approved by the person you name before they go live.

Written service levels

Response times by severity are in the agreement, and the monthly report shows how we did against them.

Your data stays in your environment

We work inside your cloud account and monitoring tools. We do not copy production data elsewhere.

Easy to leave

Dashboards, runbooks, and test sets belong to you, so another team can pick them up at any time.

Tools we use

Observability

OpenTelemetry, Grafana, Datadog, Langfuse

Evaluation

Your own test sets, run on a schedule with custom harnesses

Alerting and on-call

PagerDuty, Opsgenie, Slack, and Microsoft Teams

Cost tracking

Provider usage data and cloud cost dashboards

Ticketing

Jira, ServiceNow, or the system your team already uses

Cloud

AWS, Microsoft Azure, Google Cloud

We use the monitoring you already have wherever we can.