Included
Agreed technical care.
Monitoring, investigation, maintenance and the operating review for the named systems. Model and dependency changes are evaluated before release.
Managed AI Operations
Keep useful systems useful.
A live workflow needs an owner for its integrations, output quality and running costs. We provide the technical care and a regular review of what changed and what to do next.
For AI and automation systems already in use, built by Devopsly or by another team.
What the service watches
Per systemFive things, reviewed regularly.
HealthRuns, failures and exceptions
QualityEvaluations and user corrections
CostVolume, spend and variance
ChangeDependencies and model updates
Next actionsPriority, owner and decision
Who it is for
Notice the change
before it becomes routine.
A new document format creates more exceptions. An integration stops accepting a field. A model update changes the answer. Usage rises and the bill becomes harder to explain.
Managed operations connects those signals to the people relying on the system, with an agreed way to investigate problems, maintain the workflow and choose the next improvement.
What you receive
A regular operating review.
The review is the visible output of the service. This example shows its structure for an invoice-intake workflow. The entries are illustrative.
Operating review · invoice intake
Illustrative example| Area | What was reviewed | Example finding | Decision for the owner |
|---|---|---|---|
| Health | Runs, failures and items waiting for review. | More documents are stopping at validation since a supplier changed its invoice layout. | Approve an update to the extraction rules for that layout. |
| Quality | A sample of results against the evaluation set, plus reviewer corrections. | Corrections are concentrated in one field on scanned documents. | Keep that field in mandatory review until the next evaluation. |
| Cost | Model, cloud and platform charges against volume. | Spend rose in line with volume. No unexplained change. | None this period. |
| Change | Dependency, model and platform updates. | The model provider has announced the retirement of the version in use. | Schedule an evaluation of the replacement before migrating. |
| Incidents | Issues raised, action taken and follow-up. | One failed write to the finance system was held and retried without creating a duplicate. | Confirm the recovery steps in the operating guide. |
An example of the review format. It does not describe a client system, measured results or a committed service level.
Service boundary
What is covered, and what is not.
The boundary is written into the operating plan for each system before the service starts.
Stays with you
The business process.
A named owner decides approval policy, resolves business exceptions and authorises changes to how the work should behave.
Scoped separately
New capabilities.
New workflows and changes beyond the included effort get their own scope and quote. Other suppliers’ responsibilities are recorded, not assumed.
Service hours, incident priorities and response targets are set per system in the operating plan. We do not publish a standard service level.
How it works
Start with a proper handover.
Review the running system
Walk through the workflow, source, accounts, documentation, dependencies and current issues.
Close the operating gaps
Identify missing visibility, evaluation or recovery guidance, and scope any remediation.
Agree the operating plan
Covered systems, hours, incident priorities, review cadence, budget and who may change what.
Begin the review cycle
Report on health, quality and cost, and prioritise the next actions with the owner.
What it needs from you
Access, context and a decision owner.
- A named business owner and a technical contact.
- Source, accounts and documentation for the covered systems.
- Known issues and evaluation examples.
- Someone authorised to approve access, spending and changes.
Commitment and cost
Three separate lines.
- Recurring care. A fee for the agreed monitoring, reviews, incident handling and maintenance.
- Third-party usage. Cloud, model and platform charges, with billing ownership and spend controls stated.
- New work. Quoted separately when it exceeds the included effort.
The operating plan, issue history and configuration stay with the system, so your team or another partner can take over.
Delivered work
Operation designed in from the start.
Case study · HR and payroll
One release path, and AI changes in minutes.
For an HR and payroll assistant, one route carries every release to production, and changes to the assistant reach customer environments separately from application releases.
Read the HR assistant caseCase study · Fintech
A card product a team can release and recover.
For Flyfish’s card issuance platform: infrastructure defined in Terraform, delivery pipelines with blue-green deployments, and security controls as part of the platform.
Read the card platform caseOperations questions
Before ongoing care begins.
What hours and response times do you cover?
They are agreed for the specific system and written into the operating plan. Tell us about any out-of-hours need during scoping so the proposal matches it.
Can you support a system you did not build?
Yes, after an onboarding review of access, implementation, dependencies, documentation and current issues. Any work needed before care starts is scoped first.
Are model and cloud charges included in the fee?
No. Third-party charges and their billing owner are listed separately from the care fee, with usage reporting and spend controls.
Will you automatically switch us to the latest model?
No. A model change is evaluated for quality, cost and compatibility first, and migrated through the agreed change process.
Start with what is running
Who is looking after the workflow?
Describe the system, the people who rely on it and the care you need. We’ll reply with what an operating proposal requires.